WEBVTT 00:00:00.010 --> 00:00:04.060 Arun: So good afternoon. My name is Arun Vemury with the DHS Science 00:00:04.060 --> 00:00:08.190 and Technology Directorate. I am with the Biometric 00:00:08.190 --> 00:00:12.410 and Identity Technology Center. Thank you for joining us today for this 00:00:12.410 --> 00:00:16.500 brown bag on mobile driver's licenses challenges and opportunities for 00:00:16.500 --> 00:00:20.670 the use of these technologies as well as other digital identities. 00:00:20.670 --> 00:00:24.690 Today we are joined by a really wonderful set of folks who can talk about 00:00:24.690 --> 00:00:28.790 the various aspects of some of the work that's going on throughout the federal government to look 00:00:28.790 --> 00:00:32.980 at these technologies and to look how DHS might 00:00:32.980 --> 00:00:37.030 begin to start using them perhaps one day. So today I'll be joined 00:00:37.030 --> 00:00:41.160 by colleagues from TSA, Jason Lim the 00:00:41.160 --> 00:00:45.660 let's see if I get the title right. The Identity Management Capability Manager 00:00:45.660 --> 00:00:49.770 with Caithen Maca from NIST. Nick Orlins from Myder. 00:00:49.770 --> 00:00:53.970 So as we get started the first 00:00:53.970 --> 00:00:58.020 thing we are going to do is discuss the mobile driver's license ecosystem. 00:00:58.020 --> 00:01:02.020 So we will provide a little bit of an overview of what is mobile driver's license? 00:01:02.020 --> 00:01:06.250 What is visual identity and mDL in general. 00:01:06.250 --> 00:01:10.280 There are three roles that we identify issuer, holder and verifier. 00:01:10.280 --> 00:01:14.440 And Jason Lin from TSA will provide an explanation on some of these things. 00:01:14.440 --> 00:01:18.700 We'll talk a little bit about what it means to move from a world 00:01:18.700 --> 00:01:22.810 of physical ID documents to potentially digital ID 00:01:22.810 --> 00:01:27.020 documents. Some of the work that's going on in standards development organizations. 00:01:27.020 --> 00:01:31.080 Some additional considerations and needs. What things do we as DHS 00:01:31.080 --> 00:01:35.220 need to be thinking about that maybe other folks who are working on these technologies 00:01:35.220 --> 00:01:39.460 haven't begun working on yet. We will talk about some of the NIST work 00:01:39.460 --> 00:01:43.550 that is being led by one of our speakers Caithen here as well. 00:01:43.550 --> 00:01:47.740 We'll talk a little bit about what kinds of things DHS may need to think about. 00:01:47.740 --> 00:01:51.770 About when we start reviewing these types of documents. What are some of the securities 00:01:51.770 --> 00:01:55.890 privacy issues. What are some of the things that we might need to do to make sure that 00:01:55.890 --> 00:02:00.110 this information is being controlled properly. A discussion about 00:02:00.110 --> 00:02:04.170 qualifications versus certification programs and then a summary of some of the work 00:02:04.170 --> 00:02:08.320 that we are doing in general as well as next steps. 00:02:08.320 --> 00:02:12.580 So with that let's go on to the next slide where we will 00:02:12.580 --> 00:02:16.690 hear from Jason Lin. Jason I know you are joining us 00:02:16.690 --> 00:02:20.880 by phone, but we are on your slide and let us know when you are ready to move onto additional slides. 00:02:20.880 --> 00:02:24.930 Thank you. Jason: Sounds good Arun. Thank you very 00:02:24.930 --> 00:02:29.070 much for inviting me to this panel. Before we get into the content of this 00:02:29.070 --> 00:02:33.310 slide I just want to explain briefly the TSA identity 00:02:33.310 --> 00:02:37.390 management space, especially when it comes to passengers at the airports. 00:02:37.390 --> 00:02:41.560 So the first time you encounter a TSA 00:02:41.560 --> 00:02:45.570 officer at the airport is a position we call travel document checker. 00:02:45.570 --> 00:02:49.670 That's where you pause and hand over your ID 00:02:49.670 --> 00:02:53.870 as well as scan your boarding passes. Whether that's 00:02:53.870 --> 00:02:57.920 mobile boarding pass or physical boarding pass. So a couple of things 00:02:57.920 --> 00:03:02.050 happen from an ID management perspective here. 00:03:02.050 --> 00:03:06.280 Once you hand over your ID TSA is responsible for checking 00:03:06.280 --> 00:03:10.360 the ID to make sure it is an authentic ID, not a fake ID. 00:03:10.360 --> 00:03:14.530 The second thing that happens is that we compare the 00:03:14.530 --> 00:03:18.810 live face of the passenger against the photo on the ID 00:03:18.810 --> 00:03:22.970 to ensure that you are the same person and by 00:03:22.970 --> 00:03:27.200 scanning the boarding pass we get two pieces of information that 00:03:27.200 --> 00:03:31.270 informs the security process. The first one is your reservation status. 00:03:31.270 --> 00:03:35.450 Make sure you have a right to be there at that airport that day. 00:03:35.450 --> 00:03:39.720 And the fourth one which is TSA specific is your 00:03:39.720 --> 00:03:43.750 secure flight riding status. The secure flight is the lift engine that TSA 00:03:43.750 --> 00:03:47.960 runs in order to adjudicate potential risks of a 00:03:47.960 --> 00:03:52.010 passenger to transportation security and that 00:03:52.010 --> 00:03:56.160 is encoded in the boarding passes either your 00:03:56.160 --> 00:04:00.400 precheck or trusted traveler, or you're a standard traveler or you're a selectee 00:04:00.400 --> 00:04:04.520 and each one of those categories of passengers get 00:04:04.520 --> 00:04:08.730 different levels of physical screening. So based on all the four pieces of 00:04:08.730 --> 00:04:12.760 information you are directed to 00:04:12.760 --> 00:04:16.880 the appropriate screening lane by the officer. So all that 00:04:16.880 --> 00:04:21.250 happens within 10-12 seconds that you linger at that position. 00:04:21.250 --> 00:04:25.320 So what we've been seeing and we've been trying to stay ahead of 00:04:25.320 --> 00:04:29.680 in terms of additional identity is that, advances in identity 00:04:29.680 --> 00:04:33.920 marketplace and really the mass signals from industry partners compel TSA 00:04:33.920 --> 00:04:38.050 to examine the applicability of digital identity and digital 00:04:38.050 --> 00:04:42.290 credential to our operations specifically at that checkpoint. 00:04:42.290 --> 00:04:46.290 We do this based on physical ID, but how do we do this 00:04:46.290 --> 00:04:50.460 if someone hands over there phone or pass the phone or 00:04:50.460 --> 00:04:54.780 express to use additional ID on their smart phone. That's a specific 00:04:54.780 --> 00:04:58.910 use case that we are trying to come to grips with 00:04:58.910 --> 00:05:03.130 and have been engaging with Arun, Caithen and NIST and 00:05:03.130 --> 00:05:07.270 the industry vendors in order to understand this space. 00:05:07.270 --> 00:05:11.440 Going back to this slide briefly. Supply additional ID 00:05:11.440 --> 00:05:15.640 in TSA space we are really talking about the ID, 00:05:15.640 --> 00:05:19.760 a mobile ID that sits on your smartphone that you would use to present to TSA to get 00:05:19.760 --> 00:05:23.770 through the checkpoint. So most of that 00:05:23.770 --> 00:05:27.810 is going to be in the form of a driver's license. Currently from a physical identity 00:05:27.810 --> 00:05:31.930 document, 75% of our passengers 00:05:31.930 --> 00:05:36.160 present their driver's license as the ID at the checkpoint 00:05:36.160 --> 00:05:40.230 20% passport and 5% other 00:05:40.230 --> 00:05:44.400 forms of IDs. So with mDL kind of replacing 00:05:44.400 --> 00:05:48.400 physical driver's license we have to understand how we 00:05:48.400 --> 00:05:52.490 can accept and authenticate a mDL without a physical body to it. 00:05:52.490 --> 00:05:56.500 So that is the problem space that TSA is trying to solve. 00:05:56.500 --> 00:06:00.780 This goes to really the trustworthiness of the 00:06:00.780 --> 00:06:04.900 mDL or mobile digital ID that comes across in TSA. 00:06:04.900 --> 00:06:09.130 With the physical ID we can authenticate that the physical 00:06:09.130 --> 00:06:13.200 ID is legit by looking at the embedded visible 00:06:13.200 --> 00:06:17.540 and invisible security features. Right, so we examine 00:06:17.540 --> 00:06:21.540 that on the different light in order to tease those features out and make sure that 00:06:21.540 --> 00:06:25.640 yes this agrees with Maryland security templates 00:06:25.640 --> 00:06:29.840 that we have on file. So that's how we authenticate that this is a legitimate 00:06:29.840 --> 00:06:33.870 ID. With mDL you don't have that physical feature. 00:06:33.870 --> 00:06:38.010 So we have to rely on this triangle of trust framework that's going to be 00:06:38.010 --> 00:06:42.240 anchored by a centralized PKI. So you have three players 00:06:42.240 --> 00:06:46.320 here that plays a role. The issuing authority and that 00:06:46.320 --> 00:06:50.340 for mDL is the DMV of each jurisdiction but 00:06:50.340 --> 00:06:54.600 it could also be a private entity like the airlines can issue their own 00:06:54.600 --> 00:06:58.630 additional digital ID to their frequent flyers if they want to. 00:06:58.630 --> 00:07:02.830 But that's the issuing authority. That issuing authority 00:07:02.830 --> 00:07:06.860 provisions a person's phone, a members phone 00:07:06.860 --> 00:07:10.990 with that digital credential that sits on that phone. 00:07:10.990 --> 00:07:15.220 So that's a relationship between 1 and 2. 00:07:15.220 --> 00:07:19.310 Where TSA really comes in is as a relying party 00:07:19.310 --> 00:07:23.480 because as we are one of the largest consumers of identity at our 00:07:23.480 --> 00:07:27.690 checkpoint by 2 million plus every day that when somebody 00:07:27.690 --> 00:07:31.710 comes with a digital identity on their mobile device we have to be able to understand 00:07:31.710 --> 00:07:35.920 and authenticate that that is indeed that persons 00:07:35.920 --> 00:07:39.970 driver license. Right. So we 00:07:39.970 --> 00:07:44.110 do that through this PKI framework in which 00:07:44.110 --> 00:07:48.360 we access, or receive the public keys from the 00:07:48.360 --> 00:07:52.450 authority and then offline use case then we cache it on 00:07:52.450 --> 00:07:56.630 endpoint machines and our digital identity reader devices 00:07:56.630 --> 00:08:00.650 and in order to authenticate that credential s truly from that 00:08:00.650 --> 00:08:04.780 state and it belongs to this person who is holding their 00:08:04.780 --> 00:08:08.990 phone so this triangle of trust as I said is anchored 00:08:08.990 --> 00:08:13.050 by that centralized PKI and that's one of the largest 00:08:13.050 --> 00:08:17.210 governance issues that we are dealing with that we are asking 00:08:17.210 --> 00:08:21.460 Arun and Caiten to play key roles from a governing 00:08:21.460 --> 00:08:25.550 perspective. So a lot of talk so far but let me end my 00:08:25.550 --> 00:08:29.580 portion on this discussion by showing you 00:08:29.580 --> 00:08:33.590 two quick videos of how we actually see this happening 00:08:33.590 --> 00:08:37.700 at the checkpoint. So what you'll see are 00:08:37.700 --> 00:08:41.900 a video in which a person presents their smartphone 00:08:41.900 --> 00:08:45.940 to one of our devices that's equipped with 00:08:45.940 --> 00:08:50.080 additional reader and it will read the information coming 00:08:50.080 --> 00:08:54.320 across and also do a 1 to 2 match 00:08:54.320 --> 00:09:00.310 with a live face against a digital photo that was just passed to us. 00:09:04.690 --> 00:09:10.680 One is NFC and the other one is through QR codes. SO Arun if you could show us the videos. 00:09:25.150 --> 00:09:31.140 [Video is playing of a person using a kiosk to scan their digital mDL and their face appears on the screen] 00:09:35.290 --> 00:09:40.410 Let me wrap up with one last thought. 00:09:40.410 --> 00:09:45.530 So there is a lot of kinda standardization in those couple of seconds interactions, so I won't 00:09:45.530 --> 00:09:51.520 cover it in my presentation but I'm sure Arun and Caiten will speak 00:09:55.620 --> 00:10:00.720 more about the standards that interchange. So with that 00:10:00.720 --> 00:10:05.820 lets conclude my session. Caithen: Thank you Arun. 00:10:05.820 --> 00:10:10.960 It's great to be here and able to contribute to 00:10:10.960 --> 00:10:16.090 compare and contrast what it means to move from physical 00:10:16.090 --> 00:10:18.590 licenses to digital mDL credentials. What changes, what stays the same and how our security 00:10:18.590 --> 00:10:21.090 and privacy functions effected by that. 00:10:21.090 --> 00:10:26.400 All the proposed solutions assume preexisting for the physical ID. So it's not as traumatic as 00:10:26.400 --> 00:10:31.450 seems at first. So what that means is that 00:10:31.450 --> 00:10:36.450 the identity proofing and the creation of the initial license is inherited by the mDL process 00:10:36.450 --> 00:10:41.590 and those are not necessarily changed so that the documents that are done to establish residency 00:10:41.590 --> 00:10:46.650 etc. would be all the same. What is new for mDL is that 00:10:46.650 --> 00:10:51.880 it has a reviewing step required to generate, sign and install the license 00:10:51.880 --> 00:10:56.890 a digital license onto the user's device and there is some questioning on operations that will occur. 00:10:56.890 --> 00:11:01.980 Basically you need to be sure that you're giving it to the right person 00:11:01.980 --> 00:11:07.290 and how that is done is still the topic of some discussion. 00:11:07.290 --> 00:11:12.480 In terms of counterfeiting, there some definite differences here 00:11:12.480 --> 00:11:17.620 Jason eluded to. Physical licenses have various visible and invisible features 00:11:17.620 --> 00:11:22.700 that can be interrogated in the field or in a forensic lab to determine if they are 00:11:22.700 --> 00:11:27.930 authentic license or not. On the other hand mobile IDs use cryptographic security 00:11:27.930 --> 00:11:33.160 and digitally sign the data. So this in theory 00:11:33.160 --> 00:11:38.270 is a much, much stronger security mechanism, but it is completely different. 00:11:38.270 --> 00:11:43.270 But without the original key it's arguably impossible for a third party to produce and issue a 00:11:43.270 --> 00:11:48.290 quote sake "state license" that is digital. It's all about 00:11:48.290 --> 00:11:53.410 the key management. Presentation of the license by the 00:11:53.410 --> 00:11:58.460 user is also quite a different process. We are all familiar with presenting a physical license. 00:11:58.460 --> 00:12:03.670 It's just briefly handed over, given back, it's generally not 00:12:03.670 --> 00:12:08.700 scanned or recorded so no one else knows about it other than the person that you show it to. 00:12:08.700 --> 00:12:13.770 I know that's an important point because user's and privacy advocates 00:12:13.770 --> 00:12:18.780 assume that the license presentation of an mDL is also not recorded 00:12:18.780 --> 00:12:23.940 and this topic comes up and is relevant to the standards and how this will work. 00:12:23.940 --> 00:12:29.030 The photo presentation is also quite different because the media is different. 00:12:29.030 --> 00:12:34.040 With a driver's license you have a very small 1x1 and a quarter inch photo to look 00:12:34.040 --> 00:12:39.210 at or the examiner has to look at that and make sense of it and fairly quick 00:12:39.210 --> 00:12:44.330 cognitive task. With an mDL you can have a larger 00:12:44.330 --> 00:12:49.370 photo. You can also present it on a digital stream and there may be other photos available if there is 00:12:49.370 --> 00:12:54.630 are questions on that being the correct person. With a lost device 00:12:54.630 --> 00:12:59.780 if you lose your card your generally out of luck some good Samaritans might exist and return it to 00:12:59.780 --> 00:13:04.860 you but generally it is not recovered. If you do lose your 00:13:04.860 --> 00:13:10.100 mDL it can be regenerated and re-provisioned in the same 00:13:10.100 --> 00:13:15.290 way it was provisioned in the first place. But loosing a device is a pain, it will still leave you without 00:13:15.290 --> 00:13:20.420 your license. There are additional applications that can help you locate your device 00:13:20.420 --> 00:13:25.470 and may also be able to wipe it which you cannot do with a physical wallet and a physical license. 00:13:25.470 --> 00:13:30.690 Last if the [unintelligible] still exists 00:13:30.690 --> 00:13:35.840 as may occur with shared driver's licenses if you were getting or buying beer 00:13:35.840 --> 00:13:40.930 you'd find your twin or lookalike cousin or brother 00:13:40.930 --> 00:13:46.180 to do that. So this could still exist in the digital world that lookalikes will 00:13:46.180 --> 00:13:51.380 be there. They will potentially break some issues of trust. 00:13:51.380 --> 00:13:56.510 But so in summary the mDL is a very different ecosystem. 00:13:56.510 --> 00:14:01.570 This can require the reader, cyber infrastructure, the public key services 00:14:01.570 --> 00:14:06.790 are going to be very critical to how that works and you are going to have an over the air transmission 00:14:06.790 --> 00:14:11.950 for the interaction between the device and the reader 00:14:11.950 --> 00:14:17.040 and those are really the main things that the standards and security features are 00:14:17.040 --> 00:14:22.060 looking at in security and privacy aspects. So with that 00:14:22.060 --> 00:14:27.240 concludes my comments. Arun: Alright thanks Nick. 00:14:27.240 --> 00:14:32.360 Some of the things that we have been talking about so far within the mDL ecosystem 00:14:32.360 --> 00:14:37.410 some of the interfaces, it's important to note that these are things that 00:14:37.410 --> 00:14:42.620 honestly DHS isn't developing. No one state is developing. No one state is developing. No one technology 00:14:42.620 --> 00:14:47.770 developer is developing. This is actually built off of industry lead, voluntary 00:14:47.770 --> 00:14:52.850 consensus space standards. So these standards have been under development for a number of years 00:14:52.850 --> 00:14:58.100 primarily through an organization called ISO-IEC so 00:14:58.100 --> 00:15:03.290 this is the international organization for standards and the international electro technical. 00:15:03.290 --> 00:15:08.410 I'm probably getting the name wrong, but the point is so these are groups that 00:15:08.410 --> 00:15:13.460 around since post world war II that have facilitated the development of international standards for 00:15:13.460 --> 00:15:18.670 I guess over 70 years now. They are one of the most proven and 00:15:18.670 --> 00:15:23.830 prolific standards developments organizations out there 00:15:23.830 --> 00:15:28.910 and they have been helping to help organize meetings of international standards 00:15:28.910 --> 00:15:34.170 bodies at the national levels. We include a number of different governments 00:15:34.170 --> 00:15:39.370 different companies, a lot of different types of organizations to help bring a lot of ideas 00:15:39.370 --> 00:15:44.510 to the table here to try to make these standards as technically robust as possible. 00:15:44.510 --> 00:15:49.570 And to make sure that there is an inclusive process for collecting feedback 00:15:49.570 --> 00:15:54.790 collecting input and adjudicating the responses. That being said 00:15:54.790 --> 00:15:59.960 our standards are slower to develop. So there is a number of different standards that are currently under 00:15:59.960 --> 00:16:05.050 development or that will soon be published. So the first one listed here is the part five specification. It's the 00:16:05.050 --> 00:16:10.060 one that defines how readers, how mDL implementations 00:16:10.060 --> 00:16:15.260 on a smart phone will interact with the reader. That is up 00:16:15.260 --> 00:16:20.390 for ballot and may be finalized at the end of the year. Granted because this is a consensus building 00:16:20.390 --> 00:16:25.440 process anything can happen. It could be something that is delayed a little bit. But the point is there's 00:16:25.440 --> 00:16:30.670 a process for collecting input soliciting feedback and then working on a consensus based process 00:16:30.670 --> 00:16:35.820 to publish these standards. There are a number of other complementary standards that are also 00:16:35.820 --> 00:16:41.000 under development for conformance testing, for looking at other types of use cases for mDL. 00:16:41.000 --> 00:16:46.120 And then related standards that may be useful in looking 00:16:46.120 --> 00:16:51.310 at the issuance and provisioning process. About how a digital credential 00:16:51.310 --> 00:16:56.440 is bound to an individual perhaps through using their smartphones. 00:16:56.440 --> 00:17:01.490 So we do fully expect that there is going to be an ongoing 00:17:01.490 --> 00:17:06.710 set of technology standard development activities or standardizing and testing various 00:17:06.710 --> 00:17:11.860 aspects of this ecosystem. So additional consideration and needs. 00:17:11.860 --> 00:17:16.950 So on the previous slide we showed a few different standards that are part of the triangle of trust. 00:17:16.950 --> 00:17:22.200 That Jason briefed to us before. Some of those standards in particular the 00:17:22.200 --> 00:17:27.390 ISO-IEC 18013 part 1 and part 6 focus on the interface 00:17:27.390 --> 00:17:32.520 or the interaction between if you look at the triangle 00:17:32.520 --> 00:17:37.580 and user number 2 and the relying party number 3. So they help define the standards the 00:17:37.580 --> 00:17:42.810 interface, the methods by which you exchange information. 00:17:42.810 --> 00:17:49.030 But they don't address some of the other types of issues that we may have to worry about in the triangle of trust. 00:17:49.030 --> 00:17:54.210 So they don't address other issues such as the security or some privacy issues or 00:17:54.210 --> 00:17:59.320 some other aspects of interoperability within the overall mDL ecosystems. 00:17:59.320 --> 00:18:04.370 While the standards are good and necessary and useful some additional things may need to 00:18:04.370 --> 00:18:09.400 are going to be needed to help support a truly interoperable and 00:18:09.400 --> 00:18:14.520 trustworthy process on all fronts to make sure that issuing authorities can communicate with 00:18:14.520 --> 00:18:19.580 credentials and user's with relying parties and that the credential and user 00:18:19.580 --> 00:18:24.800 of course then can talk to the relying parties as well. So interoperability 00:18:24.800 --> 00:18:29.970 is an important aspects. Security of the data and the systems both 00:18:29.970 --> 00:18:35.070 that are being shared between the different parts of the triangle of how they are stored by 00:18:35.070 --> 00:18:40.080 the individual entities. How the encryption keys are being stored and protected 00:18:40.080 --> 00:18:45.270 by the various parties. Privacy protections of mDL user 00:18:45.270 --> 00:18:50.380 data so that 2 things obviously the data itself 00:18:50.380 --> 00:18:55.430 but that the data isn't necessarily used to perhaps track 00:18:55.430 --> 00:19:00.640 people and then helping DHS user's, components and stakeholders understand the differences 00:19:00.640 --> 00:19:05.810 between various mDL implementations. So that they understand the security and the privacy protections 00:19:05.810 --> 00:19:10.900 that are in place and help components to make informed decisions about whether or not they would like to 00:19:10.900 --> 00:19:16.170 use a technology for any particular operation. Caithen: But thanks Arun, thanks everyone for joining today. 00:19:16.170 --> 00:19:21.370 It is my pleasure to talk about the NIST work that is going 00:19:21.370 --> 00:19:26.500 on based mDL standards. So I come from the 00:19:26.500 --> 00:19:31.550 compliance division within NIST and we have spent a lot 00:19:31.550 --> 00:19:36.830 of time in writing standards. We like standards for [unintelligible] also we like 00:19:36.830 --> 00:19:41.990 writing standards for international work as well. 00:19:41.990 --> 00:19:47.090 So this standard that we have been working on ISO-1803 part five, 00:19:47.090 --> 00:19:52.110 we have been working with industry for the last few years 00:19:52.110 --> 00:19:57.290 and we came up with the version of the standard which is going to be final pretty soon. 00:19:57.290 --> 00:20:02.310 So something that follows right after writing the standard is everybody goes off and 00:20:02.310 --> 00:20:07.350 implements it but how do we make sure that everybody interprets it the same way? 00:20:07.350 --> 00:20:12.560 And there is always a chance that somebody may read the same sentence but 00:20:12.560 --> 00:20:17.700 get something different out of it. So it's important that 00:20:17.700 --> 00:20:22.770 all the vendors or implementers come up with the same solution because this standard 00:20:22.770 --> 00:20:27.790 is trying to make sure that 00:20:27.790 --> 00:20:32.950 anybody that is issued a mDL should be able to 00:20:32.950 --> 00:20:38.040 interpret with any reader that comes along. So as 00:20:38.040 --> 00:20:43.060 Jason said earlier the first thing that is going to happen is at the TSA checkpoint they are going to present 00:20:43.060 --> 00:20:48.240 your license okay. So presenting a license that TSA doesn't know anything about beforehand 00:20:48.240 --> 00:20:53.370 right. So it could come from any state. So you ideally want to make sure that 00:20:53.370 --> 00:20:58.410 before you get to that presentation that 00:20:58.410 --> 00:21:03.630 the work is done to ensure that the license will be properly read and verified by 00:21:03.630 --> 00:21:08.780 the TSA system and the same thing applies to everybody that uses relying party. So our goal with 00:21:08.780 --> 00:21:13.860 the first job is here to write the reference implementation 00:21:13.860 --> 00:21:18.570 the standard. So we are writing a reference implementation of the standard such that 00:21:18.570 --> 00:21:23.720 incorporate everything that is possible to do with the standard. Now 00:21:23.720 --> 00:21:28.790 other implementations can take and choose whatever pieces of the standard they want to implement but the 00:21:28.790 --> 00:21:34.040 reference is going to have everything. And because the reference has everything and also 00:21:34.040 --> 00:21:39.220 because we make sure it complies with the standard 00:21:39.220 --> 00:21:44.550 100% and not just our word but also we work with other experts to make sure that 00:21:44.550 --> 00:21:49.610 our interpretation is correct and accurate and regulated by other experts as well. 00:21:49.610 --> 00:21:54.840 So basically the ball for this is centered around all the 00:21:54.840 --> 00:22:00.010 possible scenarios under the mDL radar or under the implementation of 00:22:00.010 --> 00:22:05.110 standard. There are many variations in this standard 00:22:05.110 --> 00:22:10.130 that are possible which are actually here written here and we will not implement all at once. 00:22:10.130 --> 00:22:15.330 But we implement that ones that are most common, most relevant and then we keep going forward 00:22:15.330 --> 00:22:20.460 until we have implemented everything. So we will do this in phases and ultimately 00:22:20.460 --> 00:22:25.510 what we will end up getting is a reference that could 00:22:25.510 --> 00:22:30.740 be not only used by TSA but can be used by federal agencies, be used by the lenders. 00:22:30.740 --> 00:22:35.900 So for example TSA can use the reference from 00:22:35.900 --> 00:22:41.000 NIST to onboard other states, that doesn't include an mDL 00:22:41.000 --> 00:22:46.260 to get to the live scenario, you would just make sure that the mDL works with the TSA reader. 00:22:46.260 --> 00:22:51.470 So everybody can do this. Other federal agencies can do the same thing. 00:22:51.470 --> 00:22:56.600 They can take an additional step and say, you know we give this reference to the vendors and 00:22:56.600 --> 00:23:01.670 as the vendors are implementing their own mDL solution they can test their solution against this reference. 00:23:01.670 --> 00:23:06.940 So that's the goal. The goal here is to provide a reference and facilitate 00:23:06.940 --> 00:23:12.250 very fast solution development and also something 00:23:12.250 --> 00:23:17.380 that is trustworthy and something that you can be sure that incorporate 00:23:17.380 --> 00:23:22.430 production environment. So the first thing that we are working on is the 00:23:22.430 --> 00:23:27.690 reference implementation which will become available to many people. 00:23:27.690 --> 00:23:32.890 So the second thing that we are working on is the 00:23:32.890 --> 00:23:37.990 security and privacy for mDL as a whole. So as 00:23:37.990 --> 00:23:43.280 I said earlier the [unintelligible] standard focuses on the interim phase 00:23:43.280 --> 00:23:48.510 between what happens within the reader and the mDL 00:23:48.510 --> 00:23:53.670 itself in their solution. So that is equivalent to like looking at the video that Jason just 00:23:53.670 --> 00:23:58.750 showed earlier, where you just step on the reader and the reader receives the information from the 00:23:58.750 --> 00:24:04.010 mDL and it displays and verifies that it is the right person. 00:24:04.010 --> 00:24:09.030 Okay so that is the implement phase that is defined by ISO- 18013 but there are a lot of other things 00:24:09.030 --> 00:24:14.140 that goes on behind the scenes for that to work . 00:24:14.140 --> 00:24:19.170 And for that you need an entire ecosystem or you have to look at the entire lifecycle of an mDL solution. 00:24:19.170 --> 00:24:24.380 And currently since there is not any 00:24:24.380 --> 00:24:29.530 guidance on How to provision the mDL? How to recycle mDL? 00:24:29.530 --> 00:24:34.550 What should be the lifecycle of the mDL? How is mDL protected in every step of 00:24:34.550 --> 00:24:39.800 the way so for that reason we are writing 00:24:39.800 --> 00:24:44.980 security and privacy guidelines document that will provide recommendations of how 00:24:44.980 --> 00:24:50.080 to implement mDL in an ecosystem. So we will address the cross framework. 00:24:50.080 --> 00:24:55.100 We will make sure at least to define requirements for 00:24:55.100 --> 00:25:00.310 those who are managing the keys. Those who are 00:25:00.310 --> 00:25:05.450 there to make sure that the keys are secure and remain secure because you don't want somebody else to be 00:25:05.450 --> 00:25:10.500 able to steal the key and start creating fake licenses. So it's very important to secure the key 00:25:10.500 --> 00:25:16.040 for those who are issuing licenses. Now we will also 00:25:16.040 --> 00:25:21.240 provide all the details in the document, but all are going to basically make sure that the path is 00:25:21.240 --> 00:25:26.370 observed and how is that trust to be maintained and how is that trust to be 00:25:26.370 --> 00:25:31.380 sort of like transported or used utilized by different parties 00:25:31.380 --> 00:25:36.610 and so for example the line for TSA would need to know 00:25:36.610 --> 00:25:41.780 how is the state protecting the keys and then 00:25:41.780 --> 00:25:46.810 how comfortable is the state that is issuing the credential before TSA can decide that they want to accept 00:25:46.810 --> 00:25:52.090 this credential in the system. So that's where the trusted framework comes and one of the requirements 00:25:52.090 --> 00:25:57.300 for that? And then we also will deal with provisioning apps on your devices. 00:25:57.300 --> 00:26:02.430 The security of the apps on your devices. The user's of the apps on your devices. 00:26:02.430 --> 00:26:07.480 How much control does the issuer maintain on the mDL once it is issued or provisioned? 00:26:07.480 --> 00:26:12.730 So these are all the things that we need to provide 00:26:12.730 --> 00:26:17.900 enough security control at the issuance. Is there enough security controls during the 00:26:17.900 --> 00:26:23.000 lifecycle of the mDL management or the mDL? 00:26:23.000 --> 00:26:28.340 And then once the mDL lifecycle is over how do you terminate it? How do you make sure that it doesn't 00:26:28.340 --> 00:26:33.570 get used by somebody else? Or also in addition you 00:26:33.570 --> 00:26:38.740 lose your device how do you get your credential on the new device? 00:26:38.740 --> 00:26:43.820 So given this is not the physical world, there is a lot more flexibility in how you can get your 00:26:43.820 --> 00:26:49.090 mDL online. You can also 00:26:49.090 --> 00:26:54.300 do it much more [unintelligible] because with the mDL world and apps and the devices 00:26:54.300 --> 00:26:59.440 that we have today, you can provision credentials remotely and you can do things in a way 00:26:59.440 --> 00:27:04.490 much more real-time than you would be able to do with the physical world. 00:27:04.490 --> 00:27:09.740 So this final document will finally focus on the security 00:27:09.740 --> 00:27:14.910 involved in every aspect of the mDL lifecycle and we also want to make sure that 00:27:14.910 --> 00:27:20.040 the user's privacy is protected while they are using 00:27:20.040 --> 00:27:25.060 this mDL. So there will be plenty of privacy observations to be looked at 00:27:25.060 --> 00:27:30.270 in this final document. So basically this will be 00:27:30.270 --> 00:27:35.270 a version of a security and privacy 00:27:35.270 --> 00:27:40.310 integration from a NIST point of view. It is not by any means mandatory or a mandate to anyone. 00:27:40.310 --> 00:27:45.540 But it can be used as a document as a reference by others to say 00:27:45.540 --> 00:27:45.790 other things that they want the issuers to do as 00:27:45.790 --> 00:27:51.000 other things that they want the issuers to do as [unintelligible]. 00:27:51.000 --> 00:27:56.130 So this covers what's currently in the document. 00:27:56.130 --> 00:28:01.160 This is a list of all the things that we are making sure of. 00:28:01.160 --> 00:28:06.400 This is currently possible, they are making sure we cover them and this is currently 00:28:06.400 --> 00:28:11.550 where we are at, we probably are going to add more to this but this is allows a list of 00:28:11.550 --> 00:28:16.620 security and vulnerabilities that you really need to legally go through. 00:28:16.620 --> 00:28:21.870 As a implementer of mDL and make sure that you have addressed or mitigated 00:28:21.870 --> 00:28:27.050 all of these security vulnerabilities. I think that is all 00:28:27.050 --> 00:28:32.060 I had to say for now, but happy to entertain more questions later. 00:28:32.060 --> 00:28:37.080 Arun: One of the things you know, as you've heard from the briefings from Jason and Caithen, this is really 00:28:37.080 --> 00:28:42.330 about building out an ecosystem. It's not about one particular solution from one particular company 00:28:42.330 --> 00:28:47.490 or even a handful of companies. So we may end up in a situation where numerous 00:28:47.490 --> 00:28:52.550 entities, numerous groups are looking at implementing 00:28:52.550 --> 00:28:57.800 mDLs and this will probably be a combination of ID issuing or organizations 00:28:57.800 --> 00:29:02.970 which could be like state driver's license organizations. 00:29:02.970 --> 00:29:08.080 Private sector organizations, but then also people who are making apps to try to make 00:29:08.080 --> 00:29:13.110 an identity or even headset manufacturers. 00:29:13.110 --> 00:29:18.320 So all of these different entities will have a role in playing kind of in developing 00:29:18.320 --> 00:29:23.450 some of these mDL implementations that user's will use and interact with. 00:29:23.450 --> 00:29:28.520 However as Caithen pointed out, there will be when you 00:29:28.520 --> 00:29:33.770 have software there are a lot of different ways to implement some of these different solutions and controls 00:29:33.770 --> 00:29:38.940 and it's possible some implementations maybe more or less secure than others right? 00:29:38.940 --> 00:29:44.040 So in addition to the work Caithen is doing, we're also looking at developing 00:29:44.040 --> 00:29:49.060 you know criteria, processes and tests that will help us 00:29:49.060 --> 00:29:54.260 get a better understanding of what may be going on with a specific mDL implementation 00:29:54.260 --> 00:29:59.390 so that DHS and DHS components could try to better understand 00:29:59.390 --> 00:30:04.440 how the process is working, how are they assigning identity? 00:30:04.440 --> 00:30:09.680 How are they provisioning or issuing that information to a user's 00:30:09.680 --> 00:30:14.050 device? How is it protected on a user's device? Some of these important things 00:30:14.050 --> 00:30:19.070 that are useful to access the trustworthiness of a particular mDL or 00:30:19.070 --> 00:30:24.260 of the mDL ecosystem in general. So one of the things we are looking at doing is once 00:30:24.260 --> 00:30:29.390 we kind of present or identify the right criteria, the right types of tests 00:30:29.390 --> 00:30:34.440 this information can be presented to DHS components and stakeholders to determine whether 00:30:34.440 --> 00:30:39.660 or not they want to accept and use this as part of their existing operations or perhaps 00:30:39.660 --> 00:30:44.820 even new operations. So one of the things that keeps coming up is this 00:30:44.820 --> 00:30:49.900 discussion about should we be qualifying mDLs? Should we be certifying mDLs? 00:30:49.900 --> 00:30:55.180 Should we be accrediting certifiers of mDLs? So there is a 00:30:55.180 --> 00:31:00.390 lot of discussions about oh okay, if there is a lot of things out there how do we know which ones we should be 00:31:00.390 --> 00:31:05.520 using or trusting? Should DHS be in the business of testing these things? Should somebody else? 00:31:05.520 --> 00:31:10.580 So these are a lot of the things that we're still working through and discussing right now. 00:31:10.580 --> 00:31:15.820 So product certification or qualification they have 00:31:15.820 --> 00:31:21.000 similar means. So qualifications means like reviewing something to determine whether or not it 00:31:21.000 --> 00:31:26.310 meets certain criteria either in process or technology. 00:31:26.310 --> 00:31:31.340 You might even implement technology tests or prove out some sort of interoperability 00:31:31.340 --> 00:31:36.570 test or security test. Qualification is more than just 00:31:36.570 --> 00:31:41.740 I'm sorry, certification is more than just qualification. It implies that 00:31:41.740 --> 00:31:46.740 even though the terms are used interchangeably. It basically means that there is this ongoing enforcement 00:31:46.740 --> 00:31:52.000 mechanism. Right so let's say that we go ahead and test one mDL implementation 00:31:52.000 --> 00:31:57.190 are we done? If there is a software update three months from now do we 00:31:57.190 --> 00:32:02.430 need to retest? So this need about this discussion about whether or not we might 00:32:02.430 --> 00:32:07.470 need to maintain some sort of ongoing monitoring of mDL implementation 00:32:07.470 --> 00:32:12.960 retesting or evaluating whether or not they continue to meet the criteria that was previously 00:32:12.960 --> 00:32:18.140 identified. It falls more into the certifications feed. 00:32:18.140 --> 00:32:23.290 So when we talk about certification it really comes up with four different steps. It's the application process where 00:32:23.290 --> 00:32:28.320 the technology developer or a state might present something to a certification 00:32:28.320 --> 00:32:33.540 organization and say here is information about the mDL 00:32:33.540 --> 00:32:38.570 that we've implemented. Evaluation which means a technical review or a policy 00:32:38.570 --> 00:32:43.630 review of the processes technology security and privacy considerations 00:32:43.630 --> 00:32:48.870 to understand whether or not that the mDL , that particular mDL implementation meets all of those 00:32:48.870 --> 00:32:54.050 criteria. A decision process which will be a review about whether or not 00:32:54.050 --> 00:32:59.080 that the criteria to permit qualifications of the device and 00:32:59.080 --> 00:33:04.090 then potentially surveillance. Does the device continue to meet the criteria? Our security 00:33:04.090 --> 00:33:09.290 issues identified over a time that now need to be addressed and managed in order 00:33:09.290 --> 00:33:14.310 for that particular implementation to be continued to be used. 00:33:14.310 --> 00:33:19.350 So this process really goes beyond the first mDL 00:33:19.350 --> 00:33:24.570 implementation to look at okay how do we onboard an ecosystem here? How do we think about 00:33:24.570 --> 00:33:29.730 you know 50 plus organization issuing ID's working on 00:33:29.730 --> 00:33:34.800 a handful of different mobile device platforms. Different apps 00:33:34.800 --> 00:33:40.070 and make sure that they all work interoperably and that they maintain some 00:33:40.070 --> 00:33:45.080 minimum level of privacy and security requirements throughout the process so that 00:33:45.080 --> 00:33:50.200 we trust the information that is being conveyed to us. So a couple of things in summary. 00:33:50.200 --> 00:33:55.210 So DHS, so S&T actually working with TSA and NIST 00:33:55.210 --> 00:34:00.430 and a couple of other DHS components set-up a 00:34:00.430 --> 00:34:05.580 mDL and digital identity working group. And the point there is to help improve 00:34:05.580 --> 00:34:10.580 coordination on a wide range of activities going on in the area of digital identity specifically 00:34:10.580 --> 00:34:15.830 in this topic. Looking at rulemaking to process reviews 00:34:15.830 --> 00:34:21.050 and rulemaking. rulemaking and testing, I'm sorry. Testing parts of 00:34:21.050 --> 00:34:26.160 the mDL reference of implementation you know in collaboration with NIST, TSA and mDL implementers 00:34:26.160 --> 00:34:31.180 to develop this reference reader implementation so that we understand whether or not 00:34:31.180 --> 00:34:36.400 we all have a common understanding of the standard and you know we have a comfort level that 00:34:36.400 --> 00:34:41.540 we expect that there will be interoperability between systems. NIST will be continuing 00:34:41.540 --> 00:34:46.600 to work on the interagency reports. Providing recommendations and guidance 00:34:46.600 --> 00:34:51.850 on security and privacy of the information and the overall mDL ecosystem. 00:34:51.850 --> 00:34:57.030 And one of the things that we are looking at doing with the working group is putting together some 00:34:57.030 --> 00:35:02.140 notional ideas about how to develop criteria, 00:35:02.140 --> 00:35:07.160 create a review process, and refine the onboarding process 00:35:07.160 --> 00:35:12.360 in the event that we start to see lots of mDL implementations I think 00:35:12.360 --> 00:35:17.510 that where people want DHS to consider using this technology or these processes for 00:35:17.510 --> 00:35:22.560 DHS acceptance. And then also very importantly we expect that we will continue that we will continue to 00:35:22.560 --> 00:35:27.800 work with ISO ICE working groups in particular 00:35:27.800 --> 00:35:32.980 subcommittee 17 where a lot of the 00:35:32.980 --> 00:35:38.080 mDL work is happening. So we still plan to engage, provide feedback 00:35:38.080 --> 00:35:43.100 and actively participate in the development of these standards so that they can 00:35:43.100 --> 00:35:48.300 you know be shared widely within industry. And with that I think that brings us to the end 00:35:48.300 --> 00:35:52.560 of our briefing and we are happy to take any questions you all may have at this point.