Accepting the US Mobile Driver’s License with IDEMIA

Chapters

• 0:00 — Opening and introductions

• 2:44 — Introduction to remote mobile license verification

• 7:10 — How DMV enrollment establishes trust

• 9:05 — Credential security and selective disclosure

• 13:53 — TSA acceptance at national scale

• 16:43 — Identity proofing and biometric enrollment

• 20:22 — State and OEM wallet differences

• 26:04 — Current mobile license adoption

• 29:56 — Remote verification demonstration

• 37:19 — Verification speed and user experience

• 45:58 — Compliance, enrollment, and authentication questions

Full Transcript

Transcript lightly edited for clarity.

Riley Hughes: Hello everybody, and good morning. Excited to see, excited to see so many familiar names coming into the meeting and some new ones as well. So I think we'll usually like to give it a few minutes to let people trickle in. So, yeah, we'll check back in in a minute or so. Thanks everybody for joining. Okay. Let's see. See my screen okay? Rod, Paul?

Rodolphe Hugel: Yes.

Riley Hughes: Okay. I can't see the attendees, so gotta ask you. All right. Well, welcome everybody. Excited that you're here, excited to be presenting, and it's an awesome opportunity to get to do this with our colleagues at IDEMIA. So I think we're ready to get started. Today, our webinar, the topic for our webinar is accepting the U.S. mobile driver's license, in particular how to remotely verify mobile driver's licenses in the U.S. And IDEMIA is a leading provider here, both for wallets and verification solutions. Very excited to be doing the webinar together. I want to start by doing some introductions. I'm Riley. I'm one of the co-founders of Trinsic. We started Trinsic about seven-plus years ago to accelerate adoption of digital ID, in particular privacy-preserving, user-centric digital ID that puts users at the center of their data sharing and their world. And we started as a full-stack digital credential platform, and over the years have evolved as the landscape has evolved.

Riley Hughes: And today, think of us as a gateway for accepting digital IDs, including some of the wallets powered by IDEMIA, which we'll get into here. Excited to have Rod Hugel with us as well. Rod is the head of Head of Smart Connect at IDEMIA Public Security. He leads mobile or digital identity, mobile credentials, and biometric initiatives supporting governments and enterprises worldwide. Rod, great to have you.

Rodolphe Hugel: Yeah, thank you.

Riley Hughes: And Paul. Yeah, and Paul. Paul is a principal digital identity architect at IDEMIA, with more than 25 years of experience across Amazon, AWS, NIST, Deloitte, and Easy Dynamics. As a lead author of the NIST Special Publication 8633 and a board member of the FIDO Alliance, has played a significant role in advancing digital identity standards worldwide. So, Paul, thanks a lot for being here. I didn't even realize you were a lead author of the 8633 spec, so that's, yeah, learn something new every day. Great. Well, let's jump into it. I want to hand the mic over to Rod to start. So, Rod, just go ahead and shout at me when you're ready to go to the next slide, and we can go from there.

Rodolphe Hugel: Okay, good. So thank you, Riley, for inviting me. Thank you, and good morning, everyone. It's my pleasure to be discussing about one of my favorite topics, mDL. I've been in the space for now more than 15 years, and so I've been seeing this topic growing from inception to reality. So that's really exciting to be speaking about it today. And in reality, most conversation about accepting mDL eventually runs into the same question, that is, why should I trust it? Because for some people, that might seem to be new, but the reality is there's nothing really new behind the scene because we are still trusting the same issuer, that is the state DMV, that we trust for decades for issuing the driving license and the ID across the different states. So that's not something really new in terms of trust, but that's something new in terms of ecosystem and also in terms of technology. And we will go into that with the group today. What I would like also to mention is this has taken a bit of time in the making. It didn't come overnight.

Rodolphe Hugel: So I remember, you know, in the late 2014, when the NSTIC grants were launched on the first mobile ID, they were not called mDL at that time. And I remember this period because this is where, you know, some of the people in the industry vision that we would move from physical to digital started to be real and that people wanted this to happen. And that's really where I think we started to work in conjunction with the DMV, with NIST, to start implementing what we know today as an mDL. So maybe just to remind everybody about where the trust is coming from in this area, everything starts with, you know, when you're going through the DMV and you want to apply for your driving license, and that's where the foundation of the trust is built. So you probably, most of you know what it takes to get your driving license at the DMV, the in-depth identity verification that is done, all the breeder documents that you need to provide, the biometrics and underlying technology behind the scenes, making sure that you're unique.

Rodolphe Hugel: And once this verification is done, the identity is locked down in their database, and this is, you know, where they issue the physical credential. But this is also where the digital credential, the mobile driving license, takes its trust inside. So that's really important to understand that the trust is coming from all the enrollment process from the DMV. And we know that recently this process even has been strengthened thanks to the Real ID initiative. So that's something that is really key for what we are discussing today. I think one of the benefits also of the mobile driving license is the fact that by making it digital, it also improves the lifecycle management of the credential. Today, if you have to update your address or your entitlement, then you need to get a new card or you need to get a sticker that you put. So that's not something really convenient, and that is close to real time. So that's also something that the mobile driving license is bringing.

Rodolphe Hugel: So now I would like to briefly introduce, and then Paul will probably go into a bit more detail about what does it mean issuing a mobile driving license. So it's not just about putting a picture on your phone. So I remember the first discussion we had, you know, we were discussing about visual security feature on the screen. So that's not what it is. In fact, what a mobile driving license is, is a cryptographically bound credential bound to the user device and to the issuer that issued it. And in fact, the DMV starts by verifying your identity, and then the cryptographic container is put on your phone, and we generate the keys in the secure element, and we make sure that we cannot move a mobile driving license from one phone to another. And most importantly, once it's bound to the device, we also make sure that it's bound to the biometric of the user to make sure that the device, the user, and the states are always, you know, the triptic that we want to verify when we present the mobile ID.

Rodolphe Hugel: One interesting also, I would say characteristic of it is the privacy, and that's something that is difficult to do with a real ID. You know, when you have a real ID, you hand it over—I know I cannot show it on the screen—but you hand it over to the verifier, and in fact it will see all the information. You cannot hide anything. What is great with the mobile driving license is that you get the ability to select what you're going to disclose to the verifier. So that's also a great addition in the digital world, that the user can decide what he wants or doesn't want to share with the people that will verify them. So now moving a bit more on, okay, issuing a credential is a good thing. But the reality is, if you just issue, then it looks like a demo, like a picture in a smartphone, and so it doesn't really bring a lot of value. And so what is really important is to have in mind that when we issue a digital credential like an mDL, we need to find the ecosystem, the verifiers that will benefit from this issuance.

Rodolphe Hugel: And we need to be working jointly between the DMV, the different vendors of the industry, and the verifiers to make sure that this becomes a reality. Because also we need to keep in mind that usually issuers are not the main verifier of the credential. So that's really important that when you are building such an ecosystem, that you have in mind from the beginning who is going to be using it, whether it's from the verifier point of view, and also to take into consideration the user experience that goes with it. And so this is where you cannot achieve this type of ecosystem without going into standard. And so that's what Paul will cover in a minute or so. And so that's where, you know, interoperability becomes key, and the relying parties and the ecosystem around it is key. And this is where, really, I think the partnership we have with Trinsic makes a lot of sense, because if we issue a credential and nobody can use it, then, you know, it's useless. And I'm super happy to see that today we are extending, thanks to you, to the online verification to a broader ecosystem.

Rodolphe Hugel: So that's really something that we want. and that we wanted from the very beginning. So that's it for the high-level view around, you know, where does the trust come from, high level, how the mobile ID is, I would say, bound to the device. And now I would like to talk about the use case. So if we can go to the next slide, I'd like just to introduce what I call the hero use case, because when we started working on this initiative, we needed to make sure that what we were implementing was at the highest level of security. And so the most demanding use case that we identified was the TSA as a verifier, because I don't think that there's a more, I would say, demanding use case than, you know, an airport with passengers, with queues, where security is the most critical thing, and where you want to make sure that you are keeping up the highest standard in terms of trust and compliance. So that's what we built, I would say, as the first hero use case for the mDL ecosystem. And again, there, it didn't go, you know, just overnight.

Rodolphe Hugel: There were some pilots, there were some back and forth with TSA, with NIST, with DMVs and issuers to make sure that, you know, all the ecosystem was matching the TSA level of expectation in terms of security. And that's where we had to build, you know, the readers, the infrastructure, the use case, the user experience. And now I'm proud to say that this experience is now globally available in the United States. So we are present in more than 250 airports across the country. And also something that is quite unique is the fact that we were able to improve the user experience at the same time that we improved the level of security of sharing your identity when going through a TSA checkpoint. So the user experience is you tap, you look at the screen, you consent, all the information are shared and verified cryptographically, and then you're good to go once you just took yourself in front of the TSA officer. So that's really something that has improved, I would say, the user experience for the passenger, the life of the TSA border guard.

Rodolphe Hugel: And that's something that really is now, I would say, proven at scale as we speak today. So that's really something that we are very proud to have initiated as the first use case. But now the next phase is going to be the online acceptance, and that's what this webcast is about, is to move from the physical acceptance that have been proven now at scale and to move it to the online acceptance thanks to partnerships like yours, really. And so that's it for what I wanted to introduce in terms of where the trust is coming from, the first real use case that makes it feel real. And now I would like to hand it over to Paul to go a bit more into the details about how do you provision an mDL and how it's secured.

Paul Grassi: All right. Thanks, Rod. Next slide, please. So the first step, really, and I'd combine one and two, is an identity proofing step followed by enrollment. I think we got these a little bit mixed up, but that's okay. We've got two phases in our proofing and enrollment steps. The first is, as Rod mentioned, this thing is, the mDL is not only rooted in cryptography and biometrics, but also rooted in that source card. So the first thing that happens is the card would be presented to the mobile device via the camera on board, and we perform a document authentication and verification step where we ensure that that card itself is actually authentic and the information on it is valid. But that is certainly not enough. The second thing we need to do is actually capture a biometric of the individual, and we'll do that again through the mobile device or, depending on what app you're using, you can do it through your desktop app as well.

Paul Grassi: But we basically collect a biometric to perform liveness detection to make sure that the individual being presented is actually a real live human being, not a deepfake or some other type of spoof. And that is packaged up and matched against the system of record. So we actually match that biometric to the template that's stored at the— Source of record, in this case, a DMV perhaps. And that's important because a lot of the attacks that we see are at the card. So the card may be a deepfake or some other type of generated false card, where the information on it is valid. It could be my information, but the image on that is the image of the user, of the bad person presenting that card. So in that case, if you only matched on card, the bad guy could get through because their selfie will pass liveness, their selfie will match the image on the card, and the bad actor... will in fact get through.

Paul Grassi: So checking the source of record is a critical component of our solution and a critical success factor for ensuring that good individuals are actually, and the right individual is actually getting their mDL provisioned on a device. All this is founded on standards. So I would say, you know, the identity proofing step and enrollment and provisioning right now is probably most grounded on the NIST side. However, when it comes to the actual presentation of that credential, either in person, as Rod discussed with the TSA case, or online, which is where we're really looking to grow adoption, the standards there are critical. And there's three primary organizations, multiple standards that back an mDL. ISO 18013-5 is the in-person presentation. 18013-7 is remote. It's the same secure issued cryptographic credential in both of those standards. However, one is for in person and one is for online. And then under the hood, there's an Open Identity Foundation OpenID for VP, which is the protocol by which the data is actually shared.

Paul Grassi: And then depending on your use case, you could be using the W3C DC API. Which bridges all these other standards to allow the usage of mDLs on a browser and in multi- or cross-device instances. So imagine you're on a website on your desktop, but you need to present your mobile credential. The DCA facilitates that. Next slide, please. So I wanted to start, spend just a minute talking about a state wallet versus the OEM wallets. Both are important to this ecosystem, and we at IDEMIA support both. There's advantages and disadvantages to both, but I wanted to at least pinpoint some of the features of each wallet. So as you're looking at your use case, if you happen to be an issuer on the phone, this might be able to provide some insight in what the best wallet approach is for you. So you've got a state multi-credential wallet, which we support. So the state retains full control over the app, branding, content, and it's easy to add what we call derived credentials or, you know, just digital versions of a physical credential. It could be a hunting or fishing license.

Paul Grassi: It could be a vehicle registration. It could be a professional job license. Really, it could be a Medicaid card. All those could be added to the wallet and managed by the state and used by the state. And it enforces relationships between those credentials. You could have a primary being an mDL and a secondary being a registration. And of course, across both wallets, privacy and selective disclosure is built in. And Rod touched on this. What do I mean by that? I only share, I share the minimum information required. So if it's an age verification use case, I may only share that I am older than a certain age, say 21 or 25. If it's a TSA use case, I share a lot of information. It's required to get through that security checkpoint. On the OEM wallet, similar benefits. As I mentioned, privacy and selective disclosure is built in, except you're tied more to the platform owner, setting the rules and guidelines as what's eligible to live in your wallet. So today we see an OEM wallet actually supports an mDL, but may not support a vehicle registration.

Paul Grassi: It may support, in an interesting way, a vehicle registration, but there's no link linkage to it. Just like you can add a concert ticket to your wallet, maybe you can add a registration to your OEM wallet, but it's not going to speak the ISO OIDF or DC API protocols. It's not going to be inextricably tied to that primary credential called the mDL. It'll be two separate credentials used in two separate ways. And again, you're kind of, you're bound by the rules of the OEM platform provider. So I think that's it on this slide. As we've mentioned, we'll take questions at the end. So if there's anything folks would like to dig into, please add that to the chat. And with that, I'll turn it over to Riley.

Riley Hughes: Yeah. Yeah, I, yeah, just one thing to piggyback on here on the OEM wallet side, Paul, is, yeah, you're reliant on the OEM vendor for what credentials they support, but also how relying parties or businesses can get access to it. I think what I've, in talking with issuers, states, I've been surprised at times to learn that they didn't even realize that access for businesses in their state was limited based on these, you know, processes that the OEM wallets put these... companies through. And it's sometimes difficult, and they only approve certain use cases, and then it becomes a challenge.

Paul Grassi: Yep, good point.

Riley Hughes: Yeah. So adoption, adoption, it's, I think, a smart strategy to kind of go both routes so you can maximize adoption and that ecosystem, Rod, that you spoke about. Well, speaking of adoption, I think we wanted to share this slide about the potential of mobile driver's licenses in addition to kind of where they are today. So right now, if everybody woke up tomorrow morning and there was some big, you know, industrial-scale deepfake attack across a bunch of financial institutions or some other big event that happened that caused everybody in the U.S. to all of a sudden want to get a mobile driver's license, and everybody went and downloaded it, it would be about 75% of Americans, right? In other words, 75% are eligible to get a mobile driver's license. And I think, you know, basically you add Texas and Florida and you get pretty far on top of that, right? So right now, there are, I think, 24 states that issue, or 23 it says on here. I think one just decommissioned and is about to recommission again here soon, but... Yeah.

Riley Hughes: So almost half the states, roughly half the states, issue a mobile driver's license. You can add on top, you know, Puerto Rico or whatever, and you kind of get a little closer. And despite the fact that 75% of Americans could get a mobile driver's license, today roughly 2.8% of the U.S. population actually has gone out and done that, right? And that's a function of the sort of eligible population, right, like adults who are eligible for one. There's a table here on this slide that shows the states, the populations, and then kind of how they are going about issuing mobile driver's licenses and what wallets are accessible to people, and kind of shows broken down by population. And, yeah, that I guess probably won't go through all of those, but the highlights here are California is live with the mobile driver's license. New York, which we'll show a demo of here shortly, is another very large state, very populous state with a mobile ID.

Riley Hughes: And then you kind of go down the list and you can see that there are a number of these that are, I guess I wanted to mention the, let's see, Louisiana with the LA Wallet is a state that has developed a state wallet app, right, a state-specific app. And they've ended up with a great deal of adoption, right? They have several million users, and it's highly used. Another one being Arizona, the Arizona Mobile ID Wallet app, you know. Historically, I mean, this was launched quite a while ago, and I know that there's some things in Arizona that are kind of up in the air, in flux or whatever. But the Arizona Mobile ID app had a very large amount of adoption. And I think what we learned from these is that it's not just about issuing, right? As Rod said, you need to build the ecosystem around it, because in both of those states, they had a great deal of adoption because there were relying parties, there's businesses or government agencies that were accepting the credential and making it worthwhile for people to go get it, right? TSA is a great use case, right?

Riley Hughes: I use it at the TSA, but it is one that, you know, not everybody interacts with as often as some of the other use cases that, you know, people interact with their government and, you know, private sector businesses often more than they tend to travel. So what Trinsic does, what our product offering is, is essentially a gateway to enable businesses, regardless of, you know, like this is a landscape that's fairly complex. It's changing all the time. There's some wallets coming offline, a new wallet's launching. You know, states that currently work with the state wallet that all of a sudden then launch with an OEM wallet and vice versa. And so what we do is we're just a single API, a single connection, which allows companies to accept digital IDs not only across the mobile driver's license landscape, but even more broadly across the entire digital ID landscape. Like our vision is to support all the digital IDs around the world that we can get our hands on. And enable a global connectivity to privacy-preserving forms of verification for users around the world.

Riley Hughes: Currently, our network has coverage of almost 2 billion users. I'd love to get over that threshold. So if anybody, you know, knows of a wallet that has, you know, another 50 million users we could integrate, that would be great. And to kind of showcase what this looks like, we wanted to share a demo of remotely verifying a New York mobile driver's license. I think this is a good demo because it is representative of kind of what you should expect when interacting. with mobile IDs, regardless of, let's see, yeah, regardless of like state or country or whatever. There's some patterns here that I will call out as we walk through the video that basically apply to, you know, much more than just New York. So to start, as you can see on the screen, there's some kind of a landing page, right? There's some interface for the user to identify, or basically opt in or identify, oh, I have this, or I want to use this, and opt in or click into it.

Riley Hughes: You can think of this a little bit like federated identity or OpenID Connect or OAuth, these types of things where, you know, when you log in somewhere, you know, you might see the classical way of like, let me manually create a password and confirm it twice and make sure it meets all the requirements and kind of go through all that. Or I can just click login with Google, login with Microsoft, login with GitHub, whatever, right? And depending on the use case or the scenario or the business that you're interacting with, they may support a different set of login options there. If you're an enterprise, maybe SSO, etc. For mobile driver's licenses, what we found is that the, you know, a great use case for these mobile IDs is slotting them in next to workflows that require users to upload physical ID documents.

Riley Hughes: We've all probably done this a time or two in the last year or so, right, where we've wanted to rent a car online, or we've wanted to do our taxes, or we've wanted to do something like this, and we've ended up photographing a plastic card and, you know, taking a selfie and uploading that for verification. And while that's an amazing—there's some amazing innovations in, like, trying to ensure that those documents are legit and that the biometrics match and stuff, you know, it's always tough to, like, translate some physical thing into a digital form, especially when the digital form is only a few clicks away. So supporting mobile driver's licenses in these flows can be much less friction, and the user can complete the journey much faster when compared to physical ID documents. And we see that in the numbers. In our numbers and production data, we find that mobile driver's licenses are, on average, depending on which state and which, you know, which type of wallet and things like that, on average about five times faster than users who upload physical ID documents.

Riley Hughes: So going back to the demo, the first thing the user needs to do is they need to see a button and click it, right, just like you would with login with Google or something. So in this demo, we've embedded the New York Mobile ID button into this demo flow. The user clicks the button and they are redirected to a service that launches the New York Mobile ID app. When this app is launched, they authenticate. I'm just pausing here to, like, make sure that we don't blink and miss these important steps. The user authenticates to the app using, in this case, the app, the— Devices native biometric authentication, right? So in this case, it's a Face ID type of flow that the user authenticates to. Depending on the mobile ID app, this could be different. It could be something where, you know, they're allowed to use a PIN or a fingerprint or something. So some wallets even require—they don't rely on necessarily the device to authenticate the user. They may have their own biometric confirmation or something like that as well. Okay, I'm going to go over here.

Riley Hughes: Okay, so then what happens after the user authenticates to the app is they see this request from a verifier or a, you know, relying party, a business, or however you want to frame it. In this case, it's branded as Trinsic. You can see our logo here. Of course, we are not the branding that needs to be front and center. So the intended route here is that the user would see the branding of whichever business or entity they're trying to interact with. So if they're renting a car, they would see the car rental agency branding right here, et cetera. And so, you know, this entity is requesting the following information. Please review what they're going to do. The user has the opportunity to accept sharing of these values or decline them. I think seven years ago or something, when we started the company, we used to see these user interfaces where the user could then, like, check or uncheck certain attributes, right? So they could, like, uncheck, like, Oh, I don't want to share my birth date, or something, right? Or, I don't want to share my name.

Riley Hughes: And some people expect to see those types of things here. I actually think this flow that you see right here is the superior version of that, because what happens if, you know, the business you're trying to onboard to, they need to verify your age, right? Maybe it's Uber Eats. You're getting some wine alongside your food, and they need to verify you're over 21. If you uncheck date of birth, well, now they can't deliver your food or something, right? So that's, like, counterproductive, right? So the idea is the business should scope down their request to just what they need to ask for, and they shouldn't be asking for a bunch of stuff they don't need. And so there's no— I mean, it really is like, do you want to proceed with this transaction, or do you want to kind of opt out? And so in this case, the business, the car rental agency, the delivery service, whatever, will have, through Trinsic, been able to scope down their request. to just what they need to know. The user then sees that request here and has the opportunity to accept or decline.

Riley Hughes: So in this demo, we will go ahead and accept that presentation. The user sees a, you know, success screen or whatever, right? And they're prompted to go back to where they came from. So now the user can kind of, from there, close out of the app, go back to where they came from, and similar to what you might find in, like, a normal, again, login with Google, login with Microsoft, whatever kind of a flow, they redirect out, confirm that they're willing to proceed with this transaction, and then they're redirected back to wherever they came from. And maybe they have a, you know, confirmation screen to see that they are verified successfully, and then they move on with their life. So I just talked a bunch, and I have this little slide thing here. What is the— yeah, so this whole video, which includes the very beginning of the flow, including seeing the button and getting through the Cloudflare, you know, bot detection thing, all the way to the end where you're redirected back to where you came from, is 35 seconds, right?

Riley Hughes: And this includes, you know, again, pausing on a screen like this for, I don't know, seven seconds or something a few different times for the effect of the demo. So in essence, these flows can be completed very quickly. And to Rod's point about binding the user to the device, to Paul's point about the identity proofing that has gone on behind the scenes for these things and the standards that are used to cryptographically sign the— Credentials. Not only are these flows low friction, but they're very high assurance. The user has no ability to tamper with this information. And I think what's really compelling, especially in today's day and age, is there's no ability to programmatically generate 100 different, you know, versions of a mobile ID to try to share and, you know, get through or whatever, like you could with a physical ID document, right, with modern, like, AI technology. And so, yeah, go ahead and again, if you have other questions or something, drop them in the chat. I see we already have, or in the Q&A, we already have some coming in.

Riley Hughes: But yeah, feel free to ask any questions if there's anything you want to dive deeper into in there. So I think what I want to maybe emphasize more than anything is that the things we're talking about are not theoretical. Like, Trinsic has customers live in production today using mobile driver's licenses alongside their physical ID document verification and experiencing 5x faster, you know, user journeys for verification, right? I mean, they're experiencing less drop-off. They're experiencing fewer scenarios of sort of, well, they're experiencing a higher assurance form of verification, right? Like, I don't want to unequivocally say there's like no fraud or something like that, because these things are, you know, these things are new and it takes time for the ecosystem to play itself out. And I don't want to overplay the hand here, but it is important to emphasize that, yeah, this is live today. And especially, like, even going back to our slide about adoption, where there's only, you know, 3% of the U.S. adult population or something that has a mobile ID.

Riley Hughes: And so, you know, one might be asking, like, well, like, is that even worth messing with, right? Should we just wait until the adoption is higher? My answer, which is admittedly maybe a self-serving answer or something, that's why we, you know, are here or whatever, but my answer is no, right? In the same way that, you know, my note-taking app might let me, like, log in with GitHub or something. I don't have a GitHub. Well, I do, but, you know, I don't use it to log into the note-taking app. But I don't—it doesn't bother me that there's a log in with GitHub button on that screen. I mean, I just go ahead and use Google or whatever service I use and move on. It doesn't impact me. Same thing when I'm paying for something. If I see a button that says, you know, I see the enter my credit card details manually, or I see another button that says use Apple Pay or Shop Pay or Link or Google Pay or something, right? Like, I don't use Google Pay, but it doesn't bother me that Google Pay or PayPal has a button there, right? It doesn't impact my conversion at all.

Riley Hughes: And in fact, it only would help conversion if I happen to really, you know, want to use GitHub or PayPal and that button happened to be there for me. And so I think it does change some of the paradigms, and it changes maybe a little bit of the user journey and how you kind of orchestrate 17 or 14 different, like, wallet apps in the U.S. across different users and different states and different journeys and stuff. But this is what we exist to solve for. And so I would encourage you to, you know, if you're on the fence or you're thinking about it. Begin accepting mobile driver's licenses in connection with your physical ID document verification workflows right away. And only other thing I'll say here is, like, you know, I started in the space eight or nine years ago or something, and really got excited about what it means. Like, what would the world look like if everybody had privacy-preserving, high-assurance, highly trusted digital ID on their device that they always keep with them and they never, you know, leave. in the car or whatever, like I tend to do with my ID?

Riley Hughes: That would be a very good world. I would like to live in that world. And so I'm passionate about this not only because it's a product that Trinsic offers. It's actually almost the reverse. Like, the reason Trinsic offers this and the reason that we've been doing this for so long is because I want to live in a world where when I interact with my bank, I can use, I can prove who I am with a privacy-preserving digital credential, right? And so even more so than the, like, commercial impact or the private, you know, the, like, conversion boost or something like that that comes from users, my excitement about this is just primarily driven by the fact that in order for digital IDs to take off, in order for mobile driver's licenses to be successful, we need a whole ecosystem of parties around the table who are, you know, we need states to start issuing before there are verifiers lined up to accept, and we need verifiers lined up to accept before the states start issuing, and we need people who advocate to the ecosystem they interact with that they demand these types of digital credentials.

Riley Hughes: And I think that collective effort is my call to action, right? So regardless of where you're at in the ecosystem, if you're an issuer, if you're a verifier, if you are just a person, I would encourage you to get started today in whatever role makes sense for you. Okay, I will get off my soapbox there. And we can move on to our Q&A portion. Before I do, maybe Rod, Paul, anything that I missed? Anything you want to add to my little spiel here or the demo of the New York mobile ID?

Rodolphe Hugel: Oh, you did a great job. I think we are convinced, so everything went flawless. So thank you, Riley.

Riley Hughes: Great. Okay, then I think we will—let's get started on some of the Q&A. Give me a second to just read through some of these questions, and then I will—maybe, Paul, I've got one maybe for you, which is not exactly on the nose of your, the NIST work that you've done in the past, but at least is adjacently sort of related. The question is: is an mDL check enough to meet KYC or SIP compliance CIP requirements on its own, or is it used or must it be used alongside document and selfie checks? Let's see, Paul, I can't hear you. Is that me?

Rodolphe Hugel: No, we cannot hear Paul.

Riley Hughes: No worries. Let's give you a sec to see if that— While, Paul, while you're working on that, feel free to just jump in, interrupt. Oh, yeah, I can hear you now. Oh, wait, I heard something, but then I can't hear. It sounds like you have maybe a noise cancellation thing that's, like, canceling your voice or something because it's coming through.

Rodolphe Hugel: I think so.

Riley Hughes: Go ahead.

Paul Grassi: Yeah. Okay. Sorry about that. So I think the organization was the FFIEC, don't quote me on that, but yes, mDLs now, according to the regulators, can be used to satisfy at least some portion of KYC, AML, or CIP without the additional presentation of a physical license. So this was recently announced and is great news for the ecosystem and for the adoption of these new technologies.

Rodolphe Hugel: It was early September, so it's about a month ago that exactly this was a formal guidance from the Treasury, so that's helping us in what we want to achieve.

Riley Hughes: Yeah. Great. Well, any follow-ups to that, feel free to ask. I'm going to move on to one that maybe I'll answer, and then I'll ask another one for the IDEMIA folks. This question is: do you know the numbers for the actual users that have a digital passport in their wallets? So I think the context here is that in certain of the, I think now actually all three of the OEM wallets, users, if they live in a state where they don't necessarily support the... A mobile driver's license yet, or even in a state where you do, users can upload their passport into their OEM wallet, and that's usually done by reading the NFC chip on the passport. And the OEM, like the Apple, Google, Samsung, becomes the issuer of a derived credential representing that, you know, Google verified this user's passport or whatever, right? And so that's the context there. I think the answer is no, I do not know the number of actual users who have a digital passport in their wallets. Apple, Google, Samsung don't share that level of detail with us. But yeah, it's a good question.

Riley Hughes: I have heard from, I believe, all three or maybe just two out of the three, that the number of users who've obtained those digital passports is greater than what they were expecting. Like they had internal targets for, like, user adoption of this kind of thing, and that the use of these features was greater than their internal targets. I have no idea what their internal targets were, so I don't know what to think about that. It's not, you know, I don't have a benchmark necessarily. So that's all I've got. Hope that was helpful, but maybe better than nothing, maybe not. Okay, I want to move to this question. Maybe, Rod, feel free to lead out on this, and then Paul, if you want to jump in and add to it. The question is: is there any discussion within the industry to require in-person enrollment to receive an mDL versus being able to enroll in the mDL digitally or remotely? And maybe speak to, like, to the extent that there is digital enrollment, why is that as strong or maybe not as strong as in-person enrollment in the context of a mobile driver's license?

Rodolphe Hugel: Yeah, so I can certainly at least do a quick overview of that, and Paul, please complement. What we've seen so far is to ask people to go back to the DMV to get their mDL would slow down adoption. And in fact, what we feel very comfortable with in terms of technology and security is that getting access to the system of record, being able to authenticate the physical document, being able to make sure of the user presence during the enrollment—you know, what Paul mentioned when you get your mDL. Right now, most of the states, they want to stick to remote enrollment of users because we have the right technology and the right solution to prevent, you know, the deepfake attacks during this derivation of credential. And also what we've done with some states is maybe to give them the ability to have some threshold where they could have their staff remotely verifying some enrollment where there could be some doubt.

Rodolphe Hugel: You know, like if there's some risk that are flagged during the enrollment process of the mDL, then we have the ability to escalate that further in the DMV for the DMV agents to be looking at the enrollment and decide whether or not they agree to issue the mDL. And then the ultimate, you know, the ultimate, I would say, fallback would be then yes, the user would be asked to go to the DMV because we are not able to assess remotely his identity. But that's not the process that we are seeing today in the DMV. And Paul, if you want to add more on that or contradict me because maybe there's a new state that asked for that that I'm not aware of, please chime in.

Paul Grassi: No, you're right. I mean, nothing's keeping a DMV from offering in-person registration as a value add when you're actually there, but there's no requirement to do in person and bring them to the actual DMV to install this. And as you can imagine, as your mobile device... And these technologies continue to evolve. I certainly believe that the remote experience is more secure than the in-person, or will be at least more secure than the in-person. So I don't think you're going to see an in-person requirement anytime soon.

Riley Hughes: Chris, Paul, if you could just speak to that question, Q&A from Riley, I guess. Tell me more about how the remote could be more secure than the in-person, in your view. That's an interesting perspective that I'm not saying I disagree with at all. It's different than what I typically hear in the industry is people talk about it, so I want you to expand.

Paul Grassi: So, I mean, the obvious is unless the individual doing the in-person has specialized equipment, which they may have at a DMV or they will have at a DMV, just inspecting a license is not sufficient. Inspecting a breeder credential is not sufficient because no individual can examine all the security features of a given credential, and then when there's 56 different jurisdictions in the United States, to have to look at how would that occur. The DMV may be in a specialized position because they have that reader equipment to be able to verify the credential and issue it in person. So, you know, that statement would be false in that use case. But in a broader proofing sense, I would believe remote is more secure than in-person.

Riley Hughes: Yeah, and correct me if I'm wrong, but I think that the remote enrollment, because it, as a condition to, like, enroll... The user's, like, remote face or whatever is verified against the, like, government database, right? Like the database that the DMV has on file, which is very different than, like, a typical document verification workflow where you're verifying it against the picture, a picture of a picture on a plastic card, right? Versus a digital image versus a digital image, which you can get a lot more fidelity on and also, you know, you get the source of truth. kind of check. So, yeah. Yeah, great, great question. How about on the presentation of a credential, when the user has the credential in their wallet, this question says, is a biometric user verification, e.g. Face ID, required before a credential can be presented, or could wallet providers choose to rely on other methods of device unlock, passcode, PIN, etc., or no verification and just make it unauthenticated, essentially?

Riley Hughes: And is this behavior defined by a particular standard, excuse me, or is it an OEM slash state app implementation decision that will just vary by implementation?

Paul Grassi: I can answer from the standards side. I think I'd kick it over to Rod to talk about what we support today. From the standards perspective, we are looking at holder binding in a very serious way. As you probably could imagine, leveraging the platform biometric, whether it's Face ID or Touch, allows anybody enrolled in that phone to present the credential, not the actual holder. So doing biometric holder binding against the actual credential is preferred, so you know that it's being presented by the proper holder. That's what the standards are looking at. ISO is looking at that. The FIDO Alliance is looking at that. As part of the certification programs, but then I'll kick it to Rod to talk about the application we have.

Rodolphe Hugel: Yeah, so that's exactly the same alignment with our application. Although, definitely, as we are, you know, like privacy-focused, we want also to make sure that we can give the, let's say, the option to use a PIN code for when we are delivering it as our, you know, like white-label application. And we also have specific modes where, in fact, the relying party can ask and kind of impose the user presence verification, so that we do not the selfie match with the face ID, but with the wallet application algorithm, so that you don't rely on the people that has been enrolled on the phone, but you rely on what has been enrolled during the mDL issuance. So we have this type of functionality in the white-label app that IDEMIA, for example, provides to the states. That's not the way the OEM wallets are operating it. They are relying on their, you know, like operating system PIN and face or fingerprint capability. But I think as IDEMIA, we want to bring the options, and then, you know, the user, the relying party, and the issuer, they can decide to which level they want to be open or not.

Rodolphe Hugel: And then, to Paul's point, we want the biometric to be as much as possible used because that's the real assurance that the user behind the credential is the same one as the credential. It has been issued to. But, yeah, we have the flexibility at the product level.

Riley Hughes: Great. Okay, there's one that I'll take here. It says, which standards matter for online acceptance? And then it lists a handful of standards, including the ISO 18013-7, the Digital Credentials API, OpenID for VP. And are these settled enough to build on today, or which of them are settled enough to build on today? I think, you know, my answer to this is something like, you know, ideally this wouldn't need to matter, right? Ideally, if you're a technology vendor and you're integrating this at the low levels, right, then you probably already know the answer to this. If you are a relying party and you are trying to figure out how to accept digital credentials, I would encourage you to, you know, work with a partner that can abstract some of this away from you, right?

Riley Hughes: Like the whole point of Trinsic is that when, like, I think right now we support like four or five different ways of verifying the California mobile driver's license just because of the different standards that they've implemented over time and how those standards have changed and, like, backwards compatibility for some period of time and just all this stuff that, like, is way more complicated than it may seem on the surface. It's like the reason we exist. And I know, you know, probably, you know, IDEMIA would say a similar thing. I did a podcast episode with Teresa Wu, and, you know, she mentioned something very similar about working with a trusted partner to kind of help navigate some of these, you know, the landscape here. And that would be what I would say to that. And then I know we're here at time, but there's one more kind of one I wanted to ask about and see if the IDEMIA folks have any input on. It's basically just— Which use cases are most popular? Instead of, I'm combining like three different questions here, right?

Riley Hughes: But like, which use cases or where are we seeing most demand outside of the TSA for mobile driver's license acceptance?

Rodolphe Hugel: What I've seen over the last three months is in the financial industry. So it's a bit linked to the earlier question and the fact that now CIP and KYC accept digital credential as a reference. We see that all the large banks in the United States are now, you know, willing to accept mDLs. And so that's what I see from an IDEMIA point of view.

Riley Hughes: Yeah, maybe what I would add is just, I think the area where we see it the most is when mobile driver's license is used as a substitute for a picture of a plastic ID document. And so the use cases there range from financial services onboarding all the way to age verification or something, right, or hotel check-in to account recovery or workforce onboarding or background screening or something, right? So we actually see quite a lot of use cases, but kind of, or a lot of industries, maybe a lot of different types of relying parties, but focused on that one use case of optimizing that ID verification journey. That's how I'd answer it. Great. Well, characteristically of Riley, we have gone two minutes over time. So really appreciate everybody joining. If you have more questions for us, we are accessible. Respond to one of our emails we send you. We can connect you with Rod and Paul. Rod and Paul are on LinkedIn as well, each of them, so as am I. So I think safe to say reach out to any of us if you want to connect further and Again, thanks everybody for joining.

Rodolphe Hugel: Thank you all.

Paul Grassi: Thank you.

Riley Hughes: Have a good one.