In an ideal world where people control their digital data, people need to be able to hold credentials from different issuers. That means that you should be able to hold your university diploma, your driver’s license, your passport, your health insurance card, and other digital forms of personal data and mix and match those data as you see fit. Verifiers from different industries will also need to be able to read that data when presented.

Let’s use Alex, a recent college graduate applying for jobs online. In the application process, Alex needs to demonstrate that he is a resident of the state where he is applying for a job and that he received a Bachelor’s degree from an accredited university. Alex should be able to present this information together without disclosing other pieces of information that have been proven to introduce gender, racial, cultural, and pedigree bias into the hiring process, like his full legal name or the name of the university he attended.

To do that, meaning present credentials from both a university academic records department and a DMV database, we need alignment on data formats and ways to represent those data formats. Typically in markets, people think deeply about solving their own requirements – universities want to issue diplomas so that their students can get hired for jobs that require a degree. In contrast, DMVs want to issue mobile driver’s licenses to their residents to use as identification at the airport. These different siloes begin to emerge, and there is local consensus on approaches that solve the problem well for themselves while potentially extending formats to support a handful of adjacent use cases.

However, if these siloes evolve for too long, very different formats that solve abstractly similar problems surface, making it difficult to verify a mobile driver’s license and a university diploma in tandem. There likely are common actions we want to take with each of these forms of identity, like the ability to selectively disclose different attributes based on the context of the situation.

Alex might want to disclose that he is over 21 at a bar but not his home address, that he is a resident of Colorado, or his educational background. When applying for work, Alex may need to disclose that he holds a university degree but not share which institution it came from or any other unnecessary personal information. These are common features that can be abstracted into one standard, allowing different types of credentials to work together (e.g., the ability to digitally present them with ease), ensuring the correct credential is presented based on the context (e.g., age instead of degree), and shares only the information necessary (e.g., age and not address).

Driver’s licenses serve more use cases for us than just proving our capability to operate a vehicle–most residents in the United States use their driver’s license as their primary form of identification. This means that it is critical to build solutions using standardized data formats for each verifier to be able to confirm a person’s identity.

With a mobile driver’s license, Alex will want to be able to do much more than demonstrate his ability to operate a vehicle. Alex might need to be able to:

• Use his mobile driver’s license to verify his identity at a TSA checkpoint in an airport
• Verify to law enforcement he is a licensed driver if he is pulled over for a routine traffic stop in a different state from where he resides

Let’s say Alex decides he does not want to apply for a job, but rather wants to open his own consulting practice as a small business owner. In this scenario, Alex would need to be able to:

• Prove his identity online while registering for a business license with the Secretary of State in his home state
• Prove his identity online with a regional bank in order to open a small business bank account

Each of these different interactions requires that across agencies, jurisdictions, and private sector industries, we use standardized data formats that ensure interoperability across different verifiers and different wallet applications. There are various working groups and global standards bodies, which are outlined in a previous section.

The Department of Homeland Security (DHS) Science and Technology (S&T) Biometric and Identity Technology Center (BI-TC), in collaboration with the National Institute of Standards and Technology (NIST) and the Transportation Security Administration (TSA), is currently engaging various states, standards development organizations, and technology developers to assess risks and develop guidance for the development of a secure, privacy-protecting, and trustworthy digital identity ecosystem. They’ve identified the Mobile Driver’s License (mDL), as outlined in ISO/IEC 18013-5, as an early front-runner, consisting of standardized technologies and processes that enable a digital identity ecosystem that replicates and improves upon physical identity credentials.

As we build digital identity infrastructure spanning various use cases and industries, we urge implementers to create and adopt more open-source solutions. When standards are set, they need to be generalizable enough to be accepted, which means they cannot ever be completely prescriptive to every unique use case that may arise. As a result, two different implementations that may follow a standard definition correctly to the letter may not interoperate with one another. Therefore, creating standard open-source libraries allowing implementers to use the same source code front and back helps to enable trust in solutions and interoperability between different use cases.

‍