Android is ready for mobile driver's licenses, so what's the holdup?

I’ve always had the thought, “wouldn’t it be convenient if I didn’t have to carry my wallet everywhere I go?” I’d love to go out with absolutely nothing in my pockets, but that isn’t really feasible. I always carry my phone with me because it’s my lifeline in case of an emergency, it connects me to my friends and family, it lets me browse the web, and it lets me make purchases. I’ve already loaded most of my passes and credit cards onto Google Pay, so the only reason I really carry around my wallet is because it holds my ID. My driver’s license is the only card that I haven’t digitized, because if I did, it wouldn’t be an officially recognized form of ID. Until I can store my driver’s license on my phone, I’ll be carrying my wallet with me wherever I go for the foreseeable future.

Esper Device Management

In the last few years, though, there’s been a lot of work to make mobile driver’s licenses (mDLs) a reality. Tech giants like Apple and Google both announced support for mobile IDs in their respective platforms, but since this is, well, Android Dessert Bites, I’m going to focus on the latter. In this week’s post, I’ll recap the work that Google has done to make your phone a full wallet replacement. There have been some exciting developments since Google’s mDL efforts were first revealed in early 2019, but the unfortunate truth is that we’re still years away from mDLs becoming widespread. Still, I think it’s important to know where we’re at with mDL, what kind of support exists on Android, and what the biggest roadblocks are to its widespread adoption.

Why go digital?

Before I lose some of you, let me explain why I’m looking forward to mobile driver’s licenses in the first place. I’m sure the idea is anathema to some, but I think that Google lays out some fairly good arguments for why mDLs are better than the plastic cards we all carry around. First of all, they’re convenient, as I previously mentioned. One less thing to put in my pocket each day is one less thing to think about, and I never forget to bring my phone. Second, you can choose what information to share when using a mDL application. If I only need to show my ID to verify my age, then I can choose to send only my date of birth. Since DOB is often a key component of proving one's identity, though, I can choose to forego sharing that information and instead only share proof that I'm over 18 or 21 — which is the only fact bartenders or cashiers care about. For increased security, mDL apps can even implement Android’s BiometricPrompt API to require the user to authenticate with their fingerprint or face before any data is released, which is something you just can’t do with a physical ID. Third, mDLs are readily verifiable, as opposed to physical IDs which are relatively easy to fake. For these reasons, Google thinks mDL is a “big win” for end users in terms of privacy, and I agree.

Now, I’m expecting some objections to these arguments, but I assure you that most criticisms have already been considered by Google.

For example, if you’re worried that mDLs will make it easier for the police to snoop around on your phone, then you should know that mDL apps can be structured to force the phone into lockdown mode while data is being transferred from the holder to the verifier. Lockdown mode ensures that the phone can’t be unlocked without passing the primary authentication method (PIN, password, or pattern).

But what if your phone is about to run out of battery? If it did, then you wouldn’t be able to pull up your ID anyway, which would definitely put you in trouble if you’re pulled over. This is an advantage of plastic over digital, but if implemented correctly (more on that below), your digital ID can be accessed even if there isn’t enough battery left to boot the device up.

Since mDLs are digital, you may be worried about digital forgeries, but passing off a fake digital ID as the real thing would require forging a digital signature. Because the data is digitally signed by the issuing authority’s signing keys, a hacker would need to either break the relevant cryptography or steal the issuing authority’s signing keys. Both are certainly possible, but I’d wager it’s a lot easier to make a fake plastic card that can fool a bartender or cashier, so I think the benefits outweigh the risks here.

My only real concern with switching to a mDL (and a digital car key) is that increasing the importance of my smartphone will make it that much more devastating to me when it’s lost or stolen. That pain will only be temporary, though, since I can remotely wipe my phone and thus revoke access to any credentials that were stored on it. Furthermore, since the ID is digital, it’ll be easier to have it reissued to me, not to mention updating it when it’s about to expire. As for what I’d do on the day my phone gets lost or stolen, I don’t really have an answer to that except for hoping that it never happens (or to carry a backup, but then we’re back to square one).

How to go digital?

Now that I’ve (hopefully) convinced you why mobile driver’s licenses are the future, next I’ll explain what work is being done to make them a reality. We don’t know when exactly Google began work on its mDL APIs, but they must have started a few months before they submitted the AOSP code changes implementing the initial release of the IdentityCredential API. Those code changes were submitted in early 2019 ahead of the release of Android 10, which is why Google only briefly mentioned the new API at 2019’s Google I/O developer conference because it wasn’t ready to be released. With the release of Android 11 in 2020, however, the IdentityCredential API was added at the framework level along with a Hardware Abstraction Layer (HAL) that enables storing IDs in secure hardware. (The HAL is also what enables a mode called Direct Access which is what makes it possible to access IDs even when the battery is too low to boot Android.) Once the platform API was added, Google then released a Jetpack support library to make it easier for developers to build mDL apps that work on Android versions as old as Android 7.0 Nougat. So, in summary, Android has a platform API that supports storing and retrieving digital IDs, a HAL that lets those IDs be stored in secure hardware, and a support library that lets developers implement that API in their apps.

In an alternate universe, every government jumped on board with this development to immediately start issuing mobile driver’s licenses. Unfortunately, we don’t live in such a world. Instead, new technology is adopted at a glacial pace, especially when that technology needs to undergo regulatory scrutiny. That’s why I can’t point to any examples of Android’s IdentityCredential API being used to store mDLs in the wild. As far as I know, it isn’t in use by any driving license issuer. The best way I can demonstrate the API in action is through Google’s open source mDL reference applications.

In the screenshot galleries I embedded above, I show off the mDL reference app for the credential holder on one device (a Pixel 4 running Android 12) and the mDL reference app for the credential verifier on another device (a Pixel 3a XL running Android 12L). On the credential verifier, I selected the document(s) to request and then hit “next” to open a QR code scanner. On the credential holder, I tapped “present documents” to show the QR code that the verifier device needs to scan. (You’re supposed to also be able to initiate a data transfer request through NFC, but I couldn’t get this to work even after enabling NFC data retrieval in the holder app’s settings.) After authenticating my identity by scanning my face (because the holder device is a Pixel 4), the document(s) were transferred to the verifier to view.

A relatively new feature of the IdentityCredential API is the ability to present multiple documents in a single transaction. This feature was only recently added to the platform API, and it enables presenting two or more documents simultaneously. For example, if you’re asked for your driver’s license and vehicle registration information, you can present both at the same time. You can also present your driver’s license and your vaccination card when asked for both. That’s the beauty of the IdentityCredential API — it was designed to not be limited to mDLs, as the protocol in the mDL standard itself is generic. Driver’s licenses are the current focus, but I don’t see any reason COVID-19 vaccination providers can’t use the IC API to issue digital records (Google is currently pushing them to use the Google Pay Passes API, though).

It makes sense that Google is going after mDLs, though, since they’ve been planning this feature well before COVID was a thing and there’s also an agreed upon standard for how mDLs should be implemented. That standard — ISO 18013-5 — was initially released in August, so it hasn’t been that long since the industry came to an agreement on how to implement mDL apps. The committee behind the standard is already at work on future iterations of the standard (which are now sadly locked behind a paywall), but the initial publication of the standard is important for getting the slow-moving governmental entities on board. Now that it’s here, we just have to wait for them to actually recognize (or implement) mDLs apps meeting that standard.

Google hopes those apps use Android’s IdentityCredential API, which enables building an mDL app that meets the ISO 18013-5 standard, but there’s no guarantee that they will. Furthermore, there’s no guarantee that device makers will implement the IdentityCredential HAL to support storing mDLs in secure hardware, and even if they do, they’d also need to add hardware support to implement direct access mode. So far, only Google’s own Pixel phones seem to declare support for the IdentityCredential HAL, so it’s possible that this isn’t a priority for anyone but Google and some SoC vendors.

Who's going digital?

Although the IdentityCredential API hasn't been adopted by many mDL apps yet (of which there are very few in the wild), the adoption of mDL itself is on the up-and-up. As I’ve already mentioned before, Apple is fully on board with digital identification, having announced an upcoming update to its Apple Wallet app that will let iPhone users store mDLs. Though they delayed that update to sometime in “early 2022”, Apple announced that several U.S. states were planning to let their citizens add their licenses to their phones.

According to the Secure Technology Alliance, the TSA plans to begin recognizing mDLs as valid ID for domestic travel as early as next month, and at least 30 U.S. states have already issued or plan to issue mDLs as part of a pilot program. Utah, for example, is currently running a pilot program with apps developed by GET Group NA. These applications are available on Google Play and include sample data you can use to mimic an actual ID verification flow. Although the applications appear to be compliant with the ISO 18013-5 standard, a cursory analysis of their code shows they aren't utilizing Android's IC API. Still, Utah's apps nicely highlight how mDLs will work in the real world.

Outside of the U.S., I’ve seen reports that Greece and South Korea plan to make mDLs available to their citizens this year, and I’m sure more countries will adopt mDLs in the near future. But expect things to be fragmented for a long time because there are so many different entities that issue IDs. You should also expect that mDLs won’t reach your device in the near term as entities continue to run pilot programs to test the waters before rolling them out more widely. I, for one, can’t wait for mDLs to get more popular, though I don’t have much hope that my state’s (Texas) DMV will hop on board anytime soon.

Even if you still disagree with me on mobile driver’s license, I hope you learned something from reading this week’s edition of Android Dessert Bites. Beyond a brief mention at a side event at Google I/O and a few blog posts, the IdentityCredential API hasn’t been talked about much. I think it’d be great if driving license issuers or their software contractors adopted the API as it’d speed up development of ISO 18013-5 compliant mDL apps, but I don’t know how these decisions are made. All most of us can do is wait for the relevant issuing authorities to adopt mDLs one way or another.

This article was updated at 7:50 PM ET on 01/25/2022 to clarify a few details, change the title, and add screenshots from Utah's mDL apps.

This article was updated at 12:31 PM ET on 01/26/2022 to clarify that the Play Console may not list every device supporting the IC HAL.

Esper Device Management