Secure Verifiable Anywhere Anytime Digital Driver’s Licenses

Share: Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditEmail this to someonePrint this page

Today physical identity cards are used to represent personally identifiable information (PII). A common example is a driver’s license (DL) that uses paper or plastic to represent an individual’s credentials issued in compliance with ISO/IEC 18013-1. However, the representation of PII may soon be changing as the interest in mobile driver licenses is growing. As government agencies explore digital DL solutions it would be prudent for them to understand how vendors are actually representing and securing personal data.

Organizational Leadership

The American Association of Motor Vehicle Administrators (AAMVA) has published a solution needs specification for a mobile driver’s license (mDL). This specification describes several basic solution concepts:

  • A mobile driver’s license (mDL) is a digital representation of a driver’s license (DL) stored on or accessed via a device such as a smart phone or tablet.
  • A device or carrier refers to the digital medium on which a mDL resides. Typically, the mDL is contained and/or rendered by a mobile application on the device.
  • An Owner or mDL Holder pertains to the individual whose PII is represented by a mDL.
  • A Verifier or mDL Consumer is an individual that challenges an Owner to confirm the identity or privileges contained in a mDL that was issued by an Issuing Association (e.g.: DMV Agency).

AAMVA offers guidance which intentionally and appropriately does not discuss how the PII of an individual should be stored on a device. However, AAVMA does state that sufficient information must be stored on a mDL to satisfy the goals of a DL. This leaves the topic of secure data representation and packaging up to vendors that supply DMV agencies with mDL solutions.

Digital Identification Documents

didIn IBM Mobile Identity a digital identity document (DID) is a cryptographic representation of a type of identity card for an individual. Individuals have many types of identity cards. Analogous to physical identity cards, Issuing Associations are responsible for the issuing of a DID. Issuing Associations use a DID to describe a compendium of encrypted identity traits that are represented by security tokens.  Security tokens are used to prove one’s identity electronically. A Security Token acts like an electronic key to access an identifying trait. A mDL is a type of DID that is defined and managed by a specific Department of Transportation (DOT) or Department of Motor Vehicle (DMV) Agency.

The phrases a digital identity document and digital identification document are often used interchangeably. They are both referred to as a DID.

tokenized-trait
A Verifier can request any combination of tokenized identity traits from an Owner’s DID to determine if the Owner of the DID is authorized to receive services provided by the Issuing Association. These tokenized identity traits, when taken together, uniquely identify the user. By way of example, an assortment of personal traits such as height, weight, eye color and license number are defined by a state’s Department of Motor Vehicles and exist on a driver’s license to uniquely identify a driver to a highway patrolman.

Within IBM Mobile Identity a DID is a certificate of authenticity that can be rendered and proven authentic by any stakeholder in the ecosystem.

In IBM Mobile Identity a DID is securely stored in the keychain of the Owner’s device and is represented as a Standard ITU-T V3x509 Certificate using the international object identifier (OID) 1.3.18.0.2.18.6 extension. This OID was registered and issued by an International Standards (ISO) Name Registration Authority for specific use within a DID in IBM Mobile Identity. This means that a DID is represented as a secure delivery folder that is packaged using industry standards and proven encryption algorithms. For example, the OID 1.3.18.0.2.18.6 is used for PII that is encrypted with Military and Commercial (EC/RSA) DSAs and the AES128 encryption standard.

The top arcs of the international identifier tree to the OID 1.3.18.0.2.18.6 is shown below:

  • 1: International Organization for Standardization (ISO)
  • 1.3: Organization identification schemes registered according to ISO/IEC 6523-2
  • 1.3.18: Systems Network Architecture/Open Systems Interconnection (SNA/OSI) Network
  • 1.3.18.0: IBM Objects
  • 1.3.18.0.2: IBM Distributed Directory
  • 1.3.18.0.2.18: X.509 Certificate Extensions
  • 1.3.18.0.2.18.6: V3 X.509 extension Mobile Identity Container
Solution Benefits

IBM’s implementation of a DID to represent PII within a mDL solution is rooted in international standards and proven military grade cryptography. The approach also has technical importance to each of the AAMVA feature need requirements:

Requirement DID Impact
1. Capable of functioning in an off-line environment. IBM exceeds the objective to store minimally sufficient information the device to satisfy the goals of a DL. The entire mDL as issued by the Issuing Association is stored on the device and each tokenized identity trait within a DID can be proven to be authentically issued by the Issuing Association.
2. Include mechanisms that allow a Verifier to establish trust in the information provided by the mDL. Once a device specific DID is distributed to a Owner, a Verifier can request, verify and trust the data within one or more identity traits because each identity trait is cryptographically signed by an Issuing Association.
3. Confirm the mDL holder’s identity. The DID contains PII as well as cryptographic keys that allow a Verifier to confirm the identity of an individual.
4. Convey driving privileges. A privilege is represented as an identity trait which can be requested, verified and trusted.
5. Allow reading of the information across issuing authorities. Since the representation of a DID is implemented using international standards, it can be portable between interoperable solutions hosted by issuing institutions and industries.
6. Allow the mDL holder to selectively authorize the release of information. Data minimization describes the capability of a person to select one or more identity traits for use in an identity challenge. Since a DID is represented as a secure data folder, it can be programmatically searched and navigated. Therefore, Owners and Verifiers can  selectively choose identity traits within a DID for challenge request and response activity. In IBM Mobile Identity the selectivity of identity traits can span multiple DIDs. This selectivity across multiple DIDs enables individuals to have a high degree of flexibility when it comes to the sharing of their PII. For example, maybe Alice would like to use her photo from her fishing license instead of her photo from her driver’s license in response to an identification challenge at the local pharmaceutical store. This support for selectivity across multiple DIDs exceeds the AAMVA requirement and demonstrates IBM’s commitment to privacy protection.
7. Support remote mDL management. As a cryptographically secure digital object, Issuing Associations have the ability to manage the entire lifecycle of a DID on any device an Owner registers.
8. Easy to use. This topic spans multiple persona. Issuing Associations are provided a simple browser based DID editing environment. Verifiers can quickly request all or part of a DID based on the role they have been granted within the ecosystem by an Issuing Associations. Owners can automatically respond to challenges where Issuing Associations have issued the roles and identities pertinent to a challenge request.
9. Acceptable processing time. All or portions of a DID can be acquired and a challenge may be completed, each in under a minute.
Share: Share on FacebookTweet about this on TwitterShare on Google+Share on LinkedInShare on RedditEmail this to someonePrint this page
Dan Gisolfi
As CTO for Trusted Identity, Dan is focused on the development and execution of a trusted identity strategy for both citizen and corporate identity interactions using blockchain technologies. This endeavor includes the development of a formal IBM Mobile Identity offering, the definition and development of a trusted identity reference architecture, and the creation of devops tools that streamline the delivery of trusted identity solutions for clients.
Dan Gisolfi
Dan Gisolfi

Leave a Reply

Your email address will not be published. Required fields are marked *