Many U.S. states have launched mobile driver’s license pilots and conducted legislative studies, with some states nearing full-scale mDL production. An enormous benefit of providing the option of an mDL is that the mDL application can give citizens greater control over their personal data than physical cards. We’ve grown used to the privacy holes that our physical ID documents leave, but the potential of the electronic versions raises legitimate concerns about whether mDLs are in the best interest of citizen privacy. Together, we can form the business, legal and technical constructs that ensure improvement in citizen privacy without government or large-corporation intrusion.
The International Organization of Standardization’s (ISO) 18013-5 standard has made in-person mobile identity transactions with privacy protection a reality. Using this standard, mDLs will put the identity, privacy and management of data under the control of the user. ISO 18013-5 was developed based on privacy-by-design principles and has been reviewed by privacy organizations. It specifies interoperable technical mechanisms to obtain and trust the data from an mDL for in-person transactions where a data transfer is initiated and controlled by the credential holder giving affirmative consent. Future versions of ISO 18013 will include features that support automated and over-the-internet ID checks.
There are pivotal privacy principles defined by ISO/IEC 29100:2011. Citizens need these principles met to trust any new ID technology, or they won’t use it, and rightfully so. Here is how a fully 18013-5-compliant mDL or mobile ID can meet these principles:
- Consent and choice. In some models, citizens choose from a set of certified applications to hold their mDL. Consent and choice are compounded when citizens can choose identity apps. The choice of how to interact to share ID is also critical for citizen adoption and to support the situations where we check ID. Data is never shared from an ISO 18013-5-compliant app without an explicit tap or presentation of a QR. ISO 18013-5 data transmission supports either a pre-consent model (before tapping your phone) or interrupt consent model (once the verifier asks for data).
- Purpose specification / data retention. There are two recommended, non-mandatory features of ISO 18013-5 that should be used to ensure the mDL holder understands the purpose and use for their data:
- The “intent to store” flag in the protocol can inform the mDL holder that their data will be retained, and reader registration can confirm who they are interacting with. The mDL holder will be cognizant that the use case (e.g., opening a bank account) requires government-issued ID, but the verifier can further specify their intent to store the data. Often this is required by law. Verifiers should not retain data they are not required to store. The cost of data storage when breaches are calculated is exorbitantly high.
- Reader registration enables the reader device to present a verifiable certificate to the mDL holder that identifies the business requesting data. These certificates can be from the same certificate-chain as the verifier’s public website. Certificate introspection by the mDL can identify anomalies, thereby protecting the citizen.
- Data minimization. A secure mobile ID gives citizens greater control over the information they share with a verifier because ISO 18013-5-compliant mobile IDs allow for sharing subsets of the information from an ID card without compromising trust. With the physical card, all data is always shared. The late-night liquor store clerk does not need to know your address or full name. A bank does not need to know you drive a motorcycle. In the first version of ISO 18013-5, the portrait is always conveyed to the business so that the identity of the mDL holder can be verified as the rightful holder. In future versions, privacy will be improved by implementing mechanisms to trust the mDL app to perform user authentication rather than sharing portraits. This will provide a verifiable result to the business that meets their desired authentication assurance level. In either case, there is never a reason for mDL holder portraits to be stored once a transaction is approved.
Another key aspect of collection limitation is preventing the correlation of aggregated usage information so that it’s not possible to build a profile of where any one user presents their mDL. Fortunately, the driver’s license number is not at all required to approve age-based purchases nor most mDL transactions, so the mDL holder may decline to share it. ISO 18013-5 Annex E explains the requirement to rotate and randomize mDL device public keys. These public keys are the only potential correlation identifier aside from the DLN. There is no central reporting database of mDL usage, no government surveillance system, and any business that tries to centralize transactions will find it difficult to meet privacy regulations. Remember that with the physical card, the DLN is always shared. With mDL, it is not.
- Collection limitation. The complement to data minimization is when the verifier decides that it only needs a subset of identity data to approve a transaction, and therefore limits their own collection of data. Physical cards and their barcodes divulge all data to the relying party, even if they only require age and to prove it is a government-issued ID. Scanning card barcodes could leave the relying party holding data (and the liability for that data) that it does not want. ISO mDL provides the ability to ask for and validate subsets of data appropriate for the transaction. Paper does not provide this capability, as materials such as photocopies can be left out and viewable by any individual and can include excess data. The mDL can prevent over-collection by permitting a business to ask for the minimum. When businesses begin to consider the toxicity of storing data, and the fact that they can ask very quickly again for confirmation of identity, they should attempt to not store ID data at all.
- Accuracy and quality. Accuracy and quality are other areas where mDLs shine. mDL data is signed by the issuer and cryptographically verified by the verifier. This means it cannot be altered or changed along the way and the quality of the data is always in the citizen’s control. If your ID information is incorrect, fix it with your issuer and an update comes automatically. When you change information, such as your address with the DMV, information can be updated digitally in your mDL without waiting for a new card or having a mismatch between your card and new address. Citizens and verifiers (including retailers, waitstaff and bartenders, bank tellers, law enforcement and others) benefit from accurate, high quality, current data.
- Openness, transparency, individual participation. System operation can be made transparent to users through good design and meaningful user experience. ISO 18013-5 specifies only the mechanisms for obtaining and trusting subsets of data from mDLs but does not specify what the design and experience should be. As of this writing, open-source versions of the ISO 18013-5 standard are being developed, which will give those inclined to investigate a view into the operation of data interchange using mDL. It will be imperative for all ecosystem entities to educate each other on why mDL can be trusted, plus what the potential privacy pitfalls are.
- Accountability and privacy compliance. Legislative activity shown on the Secure Technology Alliance’s implementation tracker map shows states are preparing for both the acceptance of electronic credentials and the enforcement required to protect their citizens. States such as California and Virginia passed privacy legislation that protects citizens and promotes a vibrant identity ecosystem. Decentralized architectures and privacy-first policies of the trust frameworks (such as Digital ID and Authentication Council of Canada and Digital Technologies in focus in Australia) that glue these identity ecosystems together make it difficult for anyone but the citizen to know where they have used their ID. In the U.S., the Federal Trade Commission has typically handled consumer protection and resolved privacy violations.
- Information security. Single-use encryption and security mechanisms within ISO 18013-5 mean nobody can eavesdrop on “tap & go” or “scan & go” transaction sessions. During the start of offline device-retrieval of data, the reader and mDL exchange key material that ensures only they can participate in the conversation, and the conversation can only happen once. On Android platforms, Google has announced identity credential storage application programming interface services that will ensure the strongest protection of data at rest. Server retrieval mechanisms utilize API protection mechanisms standardized by Open ID Connect, which currently protect the sign-in credentials of the largest worldwide identity providers. These mechanisms assure that attributes can be retrieved only by verifiers after they’ve been given consent, and that the retrieval is encrypted and not possible to replay, eavesdrop or interrupt.
Multiple standardized interaction modes (see Chapter 2 of this white paper) with an mDL will unlock the power of mobility for obtaining trustworthy identity data. The ISO standard specifies that verifiers confirm the mDL data is unchanged and matches the official record by checking the issuer’s signature on the data. Verifiers can obtain and trust the data through different user interactions. Proximity exchange can begin with an NFC tap, or nearby exchange begins with a QR code scan. Both mean social distancing can be maintained. Once the initial token is exchanged, then the data can be shared over NFC, Bluetooth, Wi-Fi Aware, or an online Web API or OpenID Connect. This means verifiers can set up “tap & go,” “tap & hold” or “scan & request” interactions as fits their business flow, or they can develop new flows that improve customer processing speed. The ID information exchange is entirely no-contact and without the mDL holder ever giving up possession of their phone.
It is critical to note that identity privacy is always an ecosystem play. There are identity proofers, credential issuers, citizens, people within organizations, regulatory agencies and businesses that rely on identity data (relying parties). Each share responsibility to protect individual privacy, the collective effort ensuring greater than individual implementations. Every issuer within an ecosystem can implement perfect privacy but if a regulatory agency sets up a reporting system to gather usage information, or one business stores data they cannot protect, then privacy is not preserved. This can be a difficult balance to achieve, but mDLs that adhere to privacy principles are a move in the right direction. The fit of mDLs within a trust framework can round out technical architectures with business and legal constructs that ensure goals, protection, enforcement and redress of privacy.
Photo by Rodion Kutsaev on Unsplash
