So, yeah, my name is Sebastian Cavaginski. I'm a software engineer at SAMHSA Group,
it's a division of Poland. And I will be talking about the SAMHSA implementation of
OpenID for VP of a PLE, which is a PNL.
Log name. During this presentation, I will be focusing mostly on what we have learned
doing the LDI wallet prototypes, Funkspint challenge in last year, so that people who will
be actually implementing it this year, we have much easier time than us, because of the
deadlines and other stuff which forced us really have that time. I would say sometimes
doing the development. So, yeah, let's get into it.
For the start, I'll be most focusing on a few sentences about the differences between the
ISO specification and OpenID specification. Also, I will say some things which we have
we think that maybe problematic in terms of the future. And later on, we will just get into
the architecture for the wallet perspective and the implementation on Android platform.
So, yeah, I will say that the main difference is that we have actually encountered when
the formats. We have to hide the complexity for the user. He shouldn't care what he
is sharing, what his credential is actually being held in, like he shouldn't even think
about it. And that is kind of problematic. We have to abstract the credential that the user
is sharing from the actual format. And that has to be done at the start of the actually
architect in the solution, because in the long term, that will be also problematic to change.
And the main difference is for the user, I would say is the starting point. Let's imagine
a case that we are saying a car and we want to get verified. In case of the ISO specification,
we will start from the verifying site that the seller would ask the buyer to get verified.
On the other hand, in terms of OpenID, the buyer would have to request to get verified. And
let's imagine an edge case that the user from the USA comes to Germany to buy some kind
of nice car. I mean, that's actually another case. Like many people buy BMW. So, yeah,
they would have two actually options. If he had the MDR and he would also have the SD chart,
we would have a net case of the starting point. Should he actually show his QR code to start
the engagement or should he scan it? Like, now he has to think what to actually do. And that's
kind of the problematic because we want it to be as simple as possible to make the users
actually use the wallets so that the wallets will be actually used. And that's the problem actually.
We may do the best stuff in terms of the cryptography everything clearly. But at the end,
it has to be used. Otherwise, we won't have any benefit of it. And the problematic part may
be also that it doesn't allow users to select what he shares. Why the OpenID does. So, we also have to
educate the user for the second time. And that's also a problem. Educating a user is problematic.
Doing the change of the situation of the world, we had to educate users many times. And that's
another case that we have to actually educate the user again. And now we will get into the
architecture of the solution. We have speed up the main point of the app into the central,
which is the wallet holder. So, the typical user. So, I had an ID. So, I'm using that center part.
And the very fine side is using the pay fair side. Those name are specific to be the specification.
So, yeah. During the AudiI wallet.pl.types, phone calls, print challenge. We have used the
Nordic semiconductor, BED library to speed up the development. And the library has
based connection class, which hides the complexity of setting up all the connections and low-level
implementation of it. BED is problematic protocol. The connection isn't that's granted.
We can just lose the connection and we can just lose the BED connection between device and we would
have to worry about it. And the library actually takes away the hard part of it. So, yeah. That's
the stuff that would be used by any wallet to actually implement the open ID for BED quickly.
And let's get into the client's side architecture. The client in this client, in this
protocol, is the wallet. We have some kind of digital connections and we want to be able to share
it. So, we would use the client's side of the architecture. In our solution for the AudiI
challenge, we had the center connector part, which saved as a proxy to actually aggregate
all the complexity behind the protocol. So, that the entry point would be easier to actually use
for the developer. We would have some kind of simple functions to just take away the complexity
and make it simpler. So, yeah. We had this kind of repository to just scan for the
maybe devices to just look what's next to us and connect later on to it. And yeah, the important
parts are to actually not scan on the loop because we can actually make the application. We can
just get some kind of strange exceptions, which won't be able to recover from. Also, we have to
actually be aware of the limitation of scans. It's really easy to just get some kind of
unknown exceptions, because we have scans to often. So, that's also an important part,
if anybody had to develop their own wallets. We have to actually be aware of the limitations,
because there are many limitations in terms of daily for Android, which are really problematic.
Okay, we have the client connection class. That's the class which is responsible for the
connection, holding the connection, translating the data into the packets with Protobath. In
the connection, the connection and coding and encrypting, separate that. And also, the important
lesson for us was that we have to be aware that the connection itself has to be synchronous,
synchronous. We can't expect it to be actually asynchronous. It has to work in a sequence
because of the LED. As I said before, the sensor connector class was many aggregating all the
possible functions for the wallets holder, such as performing scans, sending
acknowledgments, sending identifications, observing the connected device and stuff like that.
And yeah, all the functions which are actually used in the protocol should be safe to call
from the asking kernels, asking kernels liar. So, now let's get into the
verify site architecture. It's kind of symmetric. We wanted to make it as simple as possible,
so the verify site is really just symmetric to what's on the wallets holder side. We have the
center class which connected all the functionalities, which is the paper connector. And we had classes
responsible for the connection itself, like the side of the connection and advertising, advertising
manager. And yeah, and that's really just symmetric to it. We had a class responsible for
the connection to translated data and code and crypt. So, that's really the same as before.
And yeah, the important part is that the verify can't connect quickly to many wallets.
There has to be time out between the connections otherwise. There may be some kind of left
of a package which we would receive and that would be a problem. We have to wait for the device to
actually clean up the connection. The consideration or the closing of the gut service isn't
instant. It takes some times and we have to actually wait for the device to clean everything up.
Otherwise, there will be many problems. And for example, we wouldn't be able to allow the user
to send a few consecutive credentials. So, we have to give data to that for the device to actually
clean up the connections. And yeah, this class is symmetric. It's basically providing the
functionality and hiding the complexities behind it. It's aggregating the connection, advertising,
observing the kind set of the communication. And yeah, also an important part that we have learned
is that advertising data that the verify site is broadcasting has site limitation.
Let's imagine that we want to include the device name in the data built-casted. We only have
20 bytes. So, it really is to get overflow of it. That's why we should really avoid
build casting or advertising anything that isn't actually needed because we really have some kind of
obstacle exceptions which are really hard to debug. We can just have them at the case that the user
has a really long device name. My fancy phone 1, 2, 3, 4, 5, 6. That would just cause an exception.
And we would have again problems to debug it. That may not be an issue if we have time. But
we don't really often have the time. We have to provide the wallet quickly with works and makes
it really happy. And also an important part. Android has clear limitations in terms of the
advertisement. We can't really advertise in the background. So, if we want to actually
make it that wallet holders can connect to the verify. The verify should have some kind of
screen which shows that, oh, I'm looking for wallet or stuff like that. And that's also a part
which makes it so that the user experience has to be different. So, we have to take into the
consideration when we are designed in the U.S.-based experience limitations of the platform.
And yet, that's the same stuff. This task is just as possible for the setup of the characteristics.
We can think of characteristic as an endpoint just in terms of the ability. So, that's just
the point to which we are connecting to. We don't need all sent the data.
Admit as a manager and that's the part which is problematic. Admitized data has limit of 20 bytes.
So, we have to really be aware of it. And this is the last part. Just general steps of implementation.
The verify is side. So, we have three types of characteristics, right? When we are sending the
data, the data, we have waiting and notification. Notification is the part where the client,
so wallet holder, is waiting so that the verify not, notifies him that something changed. Like,
he has received the credential. So, we can just close up the connection. That's the notification.
Okay. So, to setup the connection, we have to begin the queue of the callbacks. We have to set the
callback to make it that the wallet holders can send the data. So, that's the presented part.
Okay. So, we have to set up the callback later on. We would match the packets into one class
and just edit the event lower down the stream of our application. This is an example of sending the
data from the client perspective. We would create a prototype of class and code the data,
split it into parts and just send it to characteristic. And that's the part where we are passing
the bytes, which we have received on the client's site into a class from the photograph.
And that's basically it. So, thank you for that petition. And yeah.
Do you have fun with the questions? Do you have a question? Please raise your hand.
I would ask Sebastian to repeat the question for the folks on the livestream in the recording.
Any other questions about the pollute? There we go. Where's the limitation for the 25s coming from?
Android actually. That's Android. Oh, the question was, where's the limitation coming from the
advertised data? And that's the platform invitation. So, that's the specific part to Android.
iOS has different limitations. So, yeah.
Get a question ready now that you've implemented. So, presently credentials, you've
implemented the energy, do you think that's a good way to present credentials? Or do we need
need to look at other ways? Okay. The question was, whether I think that
BLE is a good way to present the credentials. And I think that it is. Like, we have to have some
kind of scenarios that I don't know. I don't have the intense connection. And I want to send you my data.
But NFC, QR codes, data. Yeah. But it's more comfortable. Like, we can just create some kind of
engagement, like with the QR code. I can scan it. And we don't have to actually be close
nearby. I don't know. Let's say that the COVID happens again. I hope not. We can just have some
kind of screen to, I don't know, look for people nearby and share that data. Like, I think that
is comfortable. And it makes it easy for the user. And maybe as a follow up question, or I think
it could be very friendly, but it's secure. For example, it's the high chance that I accidentally
provide my potential to end the package. No, not really. So if we're in a store, and I
think it knows in the store of the credentials are provided, they could set up some kind of
reasonably priced two. Okay. Other security issues. Okay. So the question was, whether it was
secure, it is secure. I mean, men in the middle attacks are quite common. But before the actual
exchange of the credentials, we are setting up security channel. So we are creating our own
key for the transaction. So when we are actually sending the data, it's encrypted by the key
which we only know. Okay. That's different, but like we would have to somehow verify
who we are sending the data to. Yes. And that's. Yeah. That's it. Actually, not that tricky part.
Okay. Let's dive with that. We would have to attach the wallet actually. And that's different
problem because we would have to start with the wallet attestation. And if you're speaking
about just mistaken that device was somebody else, then it's not really possible. We have to
exactly know who we are sending the data to. So we can't mistake. I don't know. You're
foreign for somebody else. That's not really possible. So if I would have to provide the credential
to you, I would have to select that I vote that it's you that I want to do. No. I would just show
you my QR code. It was kind of and it would happen in background. It would be using QR code. It's
the QR code context. The data to actually set up the connection. So yeah, because you change
the QR code. Yeah. Like when I create the QR code, I create the secret key for this
transaction. So you get the first eight bytes. Yeah. And when we actually connect, I send you
the best of the key and later on we create another key to encrypt it and create it.
Any other questions that we have one product? Yeah. I mean, thank you. I was really good
because it is a possibility to do this while your device is already or also using the
Bluetooth virtual simultaneously. What? Is it possible to do this while your device is also
using other Bluetooth virtual simultaneously? Okay. Yeah. That's different type of Bluetooth.
The question was whether it is possible to use with when the device is using, I know,
headphones, for example. And yes, it is. That's different type of Bluetooth. And it
has, even it is. Yeah. So as I said, yes. And there is an any kind of problem with it.
They did. That's. It's like, what do you need to cycle? What do you need to change?
What's the gap very close to do this? And the communication and then change back to the gap
to the Bluetooth virtual. Yeah. Like we would have to change the what we are acting
us to. Like if we are the very time site, then we have to use the paper for classes.
And if we have, if we are acting as the wallet holder, we are using the client site.
So yes, we would have to pin everything up, switch to another site and then do
the operations. I don't know if that was the answer that you were looking for. Okay.
Maybe one question about the open ID part, but you have to do this book and a laptop,
like is there any information that you can share as to how do you get some sort of metadata
to the purifier or anyway, like in this open ID. Yeah. Yeah. It's 100% offline.
The specification itself is public. It wasn't made up. I asked or anything like that.
We have just used public specification, but it isn't that I would say used to be honest.
To internet it, we have used the draft from 2024 May, which is draft CO0 and it wasn't updated.
So yeah, this was developed as a top of concept. So yeah.
Maybe small. Yeah. Was there any conclusions about the property that we took from it?
Not really. Oh, that was okay. The question was whether there was any kind of conclusion
because we have prepared the proof of concept using this protocol. There wasn't really,
but it's because we have to actually present some kind of results and we haven't done that yet.
I have to create some kind of GitHub issues and actually describe it. So that will happen,
but anytime. Question on the right. Oh, yeah. Yeah. So if I understand the spec that you're
participating in a print on the topic, right? We used to participate. We used to. Man has quite frankly,
you feel treated fairly as it was given should be an open technology discourse.
And then print actually published before this, before the end of the first round,
that they believe that not authenticated channels, like the part of the solution,
you're using other ways to go, but actually verify credentials. So you can quickly repeat,
because I didn't say running the competition published before the first round was over,
that they believe that of the two competing technical solutions authenticated channels
and verify credentials, verify credentials would be the way to go to use us,
feel that the competition was actually open and fair,
or do you feel like this actually wasn't a direct one? I think it was fair. I mean,
I have no reason to think it wasn't to be honest. Then let's talk afterwards. Okay.
Okay. I didn't expect that. I mean, sure. The other questions.
All right. Thank you, Sebastian.