WEBVTT 00:00.000 --> 00:10.000 So, yeah, my name is Sebastian Cavaginski. I'm a software engineer at SAMHSA Group, 00:10.000 --> 00:16.680 it's a division of Poland. And I will be talking about the SAMHSA implementation of 00:16.680 --> 00:21.240 OpenID for VP of a PLE, which is a PNL. 00:21.240 --> 00:27.240 Log name. During this presentation, I will be focusing mostly on what we have learned 00:27.240 --> 00:35.520 doing the LDI wallet prototypes, Funkspint challenge in last year, so that people who will 00:35.520 --> 00:40.640 be actually implementing it this year, we have much easier time than us, because of the 00:40.640 --> 00:48.640 deadlines and other stuff which forced us really have that time. I would say sometimes 00:48.640 --> 00:54.160 doing the development. So, yeah, let's get into it. 00:54.160 --> 01:00.400 For the start, I'll be most focusing on a few sentences about the differences between the 01:00.400 --> 01:09.040 ISO specification and OpenID specification. Also, I will say some things which we have 01:09.040 --> 01:15.080 we think that maybe problematic in terms of the future. And later on, we will just get into 01:15.080 --> 01:22.560 the architecture for the wallet perspective and the implementation on Android platform. 01:22.560 --> 01:33.040 So, yeah, I will say that the main difference is that we have actually encountered when 01:33.040 --> 01:38.700 the formats. We have to hide the complexity for the user. He shouldn't care what he 01:38.700 --> 01:44.640 is sharing, what his credential is actually being held in, like he shouldn't even think 01:44.640 --> 01:51.240 about it. And that is kind of problematic. We have to abstract the credential that the user 01:51.240 --> 02:00.520 is sharing from the actual format. And that has to be done at the start of the actually 02:00.520 --> 02:06.520 architect in the solution, because in the long term, that will be also problematic to change. 02:06.520 --> 02:13.400 And the main difference is for the user, I would say is the starting point. Let's imagine 02:13.400 --> 02:20.800 a case that we are saying a car and we want to get verified. In case of the ISO specification, 02:20.800 --> 02:28.800 we will start from the verifying site that the seller would ask the buyer to get verified. 02:28.800 --> 02:35.920 On the other hand, in terms of OpenID, the buyer would have to request to get verified. And 02:35.920 --> 02:40.960 let's imagine an edge case that the user from the USA comes to Germany to buy some kind 02:40.960 --> 02:48.800 of nice car. I mean, that's actually another case. Like many people buy BMW. So, yeah, 02:48.880 --> 03:00.320 they would have two actually options. If he had the MDR and he would also have the SD chart, 03:01.440 --> 03:08.960 we would have a net case of the starting point. Should he actually show his QR code to start 03:08.960 --> 03:16.240 the engagement or should he scan it? Like, now he has to think what to actually do. And that's 03:16.320 --> 03:22.560 kind of the problematic because we want it to be as simple as possible to make the users 03:22.560 --> 03:30.400 actually use the wallets so that the wallets will be actually used. And that's the problem actually. 03:30.400 --> 03:37.200 We may do the best stuff in terms of the cryptography everything clearly. But at the end, 03:37.200 --> 03:44.880 it has to be used. Otherwise, we won't have any benefit of it. And the problematic part may 03:44.880 --> 03:53.280 be also that it doesn't allow users to select what he shares. Why the OpenID does. So, we also have to 03:54.160 --> 04:01.440 educate the user for the second time. And that's also a problem. Educating a user is problematic. 04:03.200 --> 04:13.040 Doing the change of the situation of the world, we had to educate users many times. And that's 04:13.120 --> 04:21.920 another case that we have to actually educate the user again. And now we will get into the 04:23.920 --> 04:32.880 architecture of the solution. We have speed up the main point of the app into the central, 04:32.880 --> 04:41.840 which is the wallet holder. So, the typical user. So, I had an ID. So, I'm using that center part. 04:42.000 --> 04:49.600 And the very fine side is using the pay fair side. Those name are specific to be the specification. 04:52.480 --> 05:01.040 So, yeah. During the AudiI wallet.pl.types, phone calls, print challenge. We have used the 05:01.760 --> 05:08.480 Nordic semiconductor, BED library to speed up the development. And the library has 05:09.280 --> 05:17.760 based connection class, which hides the complexity of setting up all the connections and low-level 05:19.040 --> 05:28.000 implementation of it. BED is problematic protocol. The connection isn't that's granted. 05:28.560 --> 05:35.920 We can just lose the connection and we can just lose the BED connection between device and we would 05:35.920 --> 05:45.120 have to worry about it. And the library actually takes away the hard part of it. So, yeah. That's 05:45.120 --> 05:52.400 the stuff that would be used by any wallet to actually implement the open ID for BED quickly. 05:56.080 --> 06:01.360 And let's get into the client's side architecture. The client in this client, in this 06:01.360 --> 06:10.640 protocol, is the wallet. We have some kind of digital connections and we want to be able to share 06:10.640 --> 06:21.280 it. So, we would use the client's side of the architecture. In our solution for the AudiI 06:22.000 --> 06:29.120 challenge, we had the center connector part, which saved as a proxy to actually aggregate 06:30.080 --> 06:37.840 all the complexity behind the protocol. So, that the entry point would be easier to actually use 06:37.840 --> 06:44.720 for the developer. We would have some kind of simple functions to just take away the complexity 06:44.720 --> 06:55.280 and make it simpler. So, yeah. We had this kind of repository to just scan for the 06:55.280 --> 07:05.920 maybe devices to just look what's next to us and connect later on to it. And yeah, the important 07:05.920 --> 07:17.120 parts are to actually not scan on the loop because we can actually make the application. We can 07:17.120 --> 07:24.080 just get some kind of strange exceptions, which won't be able to recover from. Also, we have to 07:24.160 --> 07:30.880 actually be aware of the limitation of scans. It's really easy to just get some kind of 07:30.880 --> 07:36.560 unknown exceptions, because we have scans to often. So, that's also an important part, 07:36.560 --> 07:44.240 if anybody had to develop their own wallets. We have to actually be aware of the limitations, 07:44.240 --> 07:51.120 because there are many limitations in terms of daily for Android, which are really problematic. 07:51.600 --> 07:59.680 Okay, we have the client connection class. That's the class which is responsible for the 07:59.680 --> 08:08.880 connection, holding the connection, translating the data into the packets with Protobath. In 08:08.880 --> 08:17.200 the connection, the connection and coding and encrypting, separate that. And also, the important 08:17.280 --> 08:27.520 lesson for us was that we have to be aware that the connection itself has to be synchronous, 08:27.520 --> 08:37.600 synchronous. We can't expect it to be actually asynchronous. It has to work in a sequence 08:37.840 --> 08:48.480 because of the LED. As I said before, the sensor connector class was many aggregating all the 08:50.880 --> 08:59.120 possible functions for the wallets holder, such as performing scans, sending 08:59.120 --> 09:05.680 acknowledgments, sending identifications, observing the connected device and stuff like that. 09:07.760 --> 09:16.960 And yeah, all the functions which are actually used in the protocol should be safe to call 09:16.960 --> 09:28.880 from the asking kernels, asking kernels liar. So, now let's get into the 09:29.760 --> 09:36.160 verify site architecture. It's kind of symmetric. We wanted to make it as simple as possible, 09:36.240 --> 09:43.920 so the verify site is really just symmetric to what's on the wallets holder side. We have the 09:43.920 --> 09:53.120 center class which connected all the functionalities, which is the paper connector. And we had classes 09:53.120 --> 09:59.520 responsible for the connection itself, like the side of the connection and advertising, advertising 09:59.520 --> 10:11.280 manager. And yeah, and that's really just symmetric to it. We had a class responsible for 10:11.280 --> 10:19.440 the connection to translated data and code and crypt. So, that's really the same as before. 10:19.440 --> 10:29.440 And yeah, the important part is that the verify can't connect quickly to many wallets. 10:29.440 --> 10:36.240 There has to be time out between the connections otherwise. There may be some kind of left 10:36.240 --> 10:42.800 of a package which we would receive and that would be a problem. We have to wait for the device to 10:42.800 --> 10:50.320 actually clean up the connection. The consideration or the closing of the gut service isn't 10:50.320 --> 10:57.040 instant. It takes some times and we have to actually wait for the device to clean everything up. 10:57.040 --> 11:04.560 Otherwise, there will be many problems. And for example, we wouldn't be able to allow the user 11:04.640 --> 11:16.320 to send a few consecutive credentials. So, we have to give data to that for the device to actually 11:16.320 --> 11:28.640 clean up the connections. And yeah, this class is symmetric. It's basically providing the 11:28.720 --> 11:37.760 functionality and hiding the complexities behind it. It's aggregating the connection, advertising, 11:39.120 --> 11:49.200 observing the kind set of the communication. And yeah, also an important part that we have learned 11:49.200 --> 11:57.680 is that advertising data that the verify site is broadcasting has site limitation. 11:57.680 --> 12:05.120 Let's imagine that we want to include the device name in the data built-casted. We only have 12:05.120 --> 12:11.200 20 bytes. So, it really is to get overflow of it. That's why we should really avoid 12:11.760 --> 12:19.040 build casting or advertising anything that isn't actually needed because we really have some kind of 12:19.040 --> 12:25.680 obstacle exceptions which are really hard to debug. We can just have them at the case that the user 12:25.760 --> 12:35.280 has a really long device name. My fancy phone 1, 2, 3, 4, 5, 6. That would just cause an exception. 12:36.400 --> 12:42.720 And we would have again problems to debug it. That may not be an issue if we have time. But 12:43.360 --> 12:49.680 we don't really often have the time. We have to provide the wallet quickly with works and makes 12:49.760 --> 13:02.240 it really happy. And also an important part. Android has clear limitations in terms of the 13:03.440 --> 13:13.280 advertisement. We can't really advertise in the background. So, if we want to actually 13:14.240 --> 13:21.680 make it that wallet holders can connect to the verify. The verify should have some kind of 13:24.000 --> 13:29.680 screen which shows that, oh, I'm looking for wallet or stuff like that. And that's also a part 13:30.720 --> 13:37.680 which makes it so that the user experience has to be different. So, we have to take into the 13:37.680 --> 13:45.200 consideration when we are designed in the U.S.-based experience limitations of the platform. 13:49.520 --> 13:56.160 And yet, that's the same stuff. This task is just as possible for the setup of the characteristics. 13:57.520 --> 14:04.480 We can think of characteristic as an endpoint just in terms of the ability. So, that's just 14:05.280 --> 14:09.920 the point to which we are connecting to. We don't need all sent the data. 14:14.480 --> 14:22.160 Admit as a manager and that's the part which is problematic. Admitized data has limit of 20 bytes. 14:22.880 --> 14:33.760 So, we have to really be aware of it. And this is the last part. Just general steps of implementation. 14:33.840 --> 14:43.200 The verify is side. So, we have three types of characteristics, right? When we are sending the 14:43.200 --> 14:52.960 data, the data, we have waiting and notification. Notification is the part where the client, 14:52.960 --> 15:01.920 so wallet holder, is waiting so that the verify not, notifies him that something changed. Like, 15:02.000 --> 15:07.120 he has received the credential. So, we can just close up the connection. That's the notification. 15:09.440 --> 15:18.000 Okay. So, to setup the connection, we have to begin the queue of the callbacks. We have to set the 15:19.440 --> 15:26.000 callback to make it that the wallet holders can send the data. So, that's the presented part. 15:26.000 --> 15:35.680 Okay. So, we have to set up the callback later on. We would match the packets into one class 15:36.960 --> 15:46.320 and just edit the event lower down the stream of our application. This is an example of sending the 15:46.320 --> 15:53.840 data from the client perspective. We would create a prototype of class and code the data, 15:54.320 --> 16:04.880 split it into parts and just send it to characteristic. And that's the part where we are passing 16:04.880 --> 16:13.200 the bytes, which we have received on the client's site into a class from the photograph. 16:13.920 --> 16:22.080 And that's basically it. So, thank you for that petition. And yeah. 16:25.120 --> 16:27.920 Do you have fun with the questions? Do you have a question? Please raise your hand. 16:27.920 --> 16:31.840 I would ask Sebastian to repeat the question for the folks on the livestream in the recording. 16:32.640 --> 16:38.000 Any other questions about the pollute? There we go. Where's the limitation for the 25s coming from? 16:38.640 --> 16:45.200 Android actually. That's Android. Oh, the question was, where's the limitation coming from the 16:45.760 --> 16:52.080 advertised data? And that's the platform invitation. So, that's the specific part to Android. 16:52.080 --> 16:55.920 iOS has different limitations. So, yeah. 16:57.280 --> 17:03.440 Get a question ready now that you've implemented. So, presently credentials, you've 17:03.440 --> 17:07.600 implemented the energy, do you think that's a good way to present credentials? Or do we need 17:07.600 --> 17:12.880 need to look at other ways? Okay. The question was, whether I think that 17:13.680 --> 17:18.400 BLE is a good way to present the credentials. And I think that it is. Like, we have to have some 17:18.400 --> 17:23.840 kind of scenarios that I don't know. I don't have the intense connection. And I want to send you my data. 17:23.840 --> 17:32.880 But NFC, QR codes, data. Yeah. But it's more comfortable. Like, we can just create some kind of 17:32.880 --> 17:38.320 engagement, like with the QR code. I can scan it. And we don't have to actually be close 17:38.320 --> 17:43.680 nearby. I don't know. Let's say that the COVID happens again. I hope not. We can just have some 17:43.680 --> 17:49.920 kind of screen to, I don't know, look for people nearby and share that data. Like, I think that 17:49.920 --> 17:55.680 is comfortable. And it makes it easy for the user. And maybe as a follow up question, or I think 17:55.680 --> 18:00.800 it could be very friendly, but it's secure. For example, it's the high chance that I accidentally 18:00.880 --> 18:05.840 provide my potential to end the package. No, not really. So if we're in a store, and I 18:05.840 --> 18:09.360 think it knows in the store of the credentials are provided, they could set up some kind of 18:09.360 --> 18:17.680 reasonably priced two. Okay. Other security issues. Okay. So the question was, whether it was 18:17.680 --> 18:25.680 secure, it is secure. I mean, men in the middle attacks are quite common. But before the actual 18:26.240 --> 18:34.240 exchange of the credentials, we are setting up security channel. So we are creating our own 18:34.240 --> 18:41.120 key for the transaction. So when we are actually sending the data, it's encrypted by the key 18:41.120 --> 18:54.880 which we only know. Okay. That's different, but like we would have to somehow verify 18:55.680 --> 19:03.760 who we are sending the data to. Yes. And that's. Yeah. That's it. Actually, not that tricky part. 19:07.280 --> 19:12.640 Okay. Let's dive with that. We would have to attach the wallet actually. And that's different 19:12.640 --> 19:17.040 problem because we would have to start with the wallet attestation. And if you're speaking 19:17.040 --> 19:23.600 about just mistaken that device was somebody else, then it's not really possible. We have to 19:23.600 --> 19:29.600 exactly know who we are sending the data to. So we can't mistake. I don't know. You're 19:29.600 --> 19:35.360 foreign for somebody else. That's not really possible. So if I would have to provide the credential 19:35.360 --> 19:40.960 to you, I would have to select that I vote that it's you that I want to do. No. I would just show 19:40.960 --> 19:44.880 you my QR code. It was kind of and it would happen in background. It would be using QR code. It's 19:46.880 --> 19:52.400 the QR code context. The data to actually set up the connection. So yeah, because you change 19:52.880 --> 19:57.680 the QR code. Yeah. Like when I create the QR code, I create the secret key for this 19:57.680 --> 20:03.680 transaction. So you get the first eight bytes. Yeah. And when we actually connect, I send you 20:04.800 --> 20:09.440 the best of the key and later on we create another key to encrypt it and create it. 20:11.440 --> 20:16.400 Any other questions that we have one product? Yeah. I mean, thank you. I was really good 20:16.400 --> 20:21.840 because it is a possibility to do this while your device is already or also using the 20:21.840 --> 20:26.880 Bluetooth virtual simultaneously. What? Is it possible to do this while your device is also 20:26.880 --> 20:33.760 using other Bluetooth virtual simultaneously? Okay. Yeah. That's different type of Bluetooth. 20:35.120 --> 20:39.680 The question was whether it is possible to use with when the device is using, I know, 20:39.760 --> 20:45.200 headphones, for example. And yes, it is. That's different type of Bluetooth. And it 20:45.200 --> 20:56.080 has, even it is. Yeah. So as I said, yes. And there is an any kind of problem with it. 20:56.080 --> 21:00.080 They did. That's. It's like, what do you need to cycle? What do you need to change? 21:00.080 --> 21:03.280 What's the gap very close to do this? And the communication and then change back to the gap 21:03.760 --> 21:11.360 to the Bluetooth virtual. Yeah. Like we would have to change the what we are acting 21:11.360 --> 21:18.240 us to. Like if we are the very time site, then we have to use the paper for classes. 21:18.960 --> 21:24.400 And if we have, if we are acting as the wallet holder, we are using the client site. 21:25.600 --> 21:30.800 So yes, we would have to pin everything up, switch to another site and then do 21:30.880 --> 21:38.720 the operations. I don't know if that was the answer that you were looking for. Okay. 21:40.320 --> 21:44.800 Maybe one question about the open ID part, but you have to do this book and a laptop, 21:44.800 --> 21:52.160 like is there any information that you can share as to how do you get some sort of metadata 21:52.640 --> 22:04.000 to the purifier or anyway, like in this open ID. Yeah. Yeah. It's 100% offline. 22:04.000 --> 22:10.480 The specification itself is public. It wasn't made up. I asked or anything like that. 22:10.480 --> 22:17.600 We have just used public specification, but it isn't that I would say used to be honest. 22:17.920 --> 22:28.160 To internet it, we have used the draft from 2024 May, which is draft CO0 and it wasn't updated. 22:30.000 --> 22:35.120 So yeah, this was developed as a top of concept. So yeah. 22:36.720 --> 22:41.920 Maybe small. Yeah. Was there any conclusions about the property that we took from it? 22:42.240 --> 22:51.120 Not really. Oh, that was okay. The question was whether there was any kind of conclusion 22:51.120 --> 22:56.800 because we have prepared the proof of concept using this protocol. There wasn't really, 22:57.520 --> 23:03.040 but it's because we have to actually present some kind of results and we haven't done that yet. 23:03.040 --> 23:10.640 I have to create some kind of GitHub issues and actually describe it. So that will happen, 23:10.640 --> 23:18.880 but anytime. Question on the right. Oh, yeah. Yeah. So if I understand the spec that you're 23:18.880 --> 23:27.680 participating in a print on the topic, right? We used to participate. We used to. Man has quite frankly, 23:27.680 --> 23:33.120 you feel treated fairly as it was given should be an open technology discourse. 23:33.680 --> 23:37.920 And then print actually published before this, before the end of the first round, 23:37.920 --> 23:42.160 that they believe that not authenticated channels, like the part of the solution, 23:42.160 --> 23:47.120 you're using other ways to go, but actually verify credentials. So you can quickly repeat, 23:47.120 --> 23:54.560 because I didn't say running the competition published before the first round was over, 23:54.960 --> 23:59.120 that they believe that of the two competing technical solutions authenticated channels 23:59.120 --> 24:04.640 and verify credentials, verify credentials would be the way to go to use us, 24:04.720 --> 24:07.840 feel that the competition was actually open and fair, 24:07.840 --> 24:13.280 or do you feel like this actually wasn't a direct one? I think it was fair. I mean, 24:13.280 --> 24:18.800 I have no reason to think it wasn't to be honest. Then let's talk afterwards. Okay. 24:18.800 --> 24:22.960 Okay. I didn't expect that. I mean, sure. The other questions. 24:27.200 --> 24:28.960 All right. Thank you, Sebastian.