Thank you. So good, good morning. My name is Jo. I work for Yuko. And the previous two presentations were a perfect introduction to my presentation because I'd like to discuss a wallet that's actually, so, so it's, it's intended for the EU Digital Identity Wallet, and it's using Fido to secure this wallet. So I work for ubi, but this is a joint project with Gnet and Sunnet. Sunnet is the, the, the National Research and Education Network in Sweden. And Gnet is the Greek university network. They are all evolved in the large scale pilots.
So Gnet and Sunnet are involved in DC for, for eu, where they do academic credential use cases, for example. And UBI and Sunnet are in EWC where we are focusing on organizational wallets. So Sunnet and Gnet already embarked on this, on this project.
We, they asked us could we use Fido to secure this wallet because this is a, a particular wallet, it's a, it's a web wallet.
So that's basically the content of, of my presentation. So let me test the clicker. It works. So I'm not gonna spend a lot of time on this slide. I think most people know what pass keys are and security keys, but just to make sure, so, so a pass key is typically stored on an authenticator, and one particular type of authenticator is a security key, things like this. So this is ours, but there are many vendors that create these Fido security keys.
And the idea is to, to use this in a, in a wallet. So just a couple of properties of pass keys and security keys that are relevant for building a web wallet. So one is that you, you can protect the, these pass keys that are used with secure hardware. So this is relevant for, for example, for pits, right? There will be requirements on the, the protection of the, of the verifiable credentials.
And you can use secure hardware for this.
And, and that is perfectly covered with, with fighter security keys. So multifactor authentication, phishing resistance, these properties have all been mentioned in, in the previous presentations, it supported all, all major web browsers. So that makes it interesting. So could we build a EU digital identity wallet using just a web browser? So instead of using a native app on Android or Apple, can we do it independently from those platforms using just web technology? And we think the answer is yes. So what is this thing? A web-based wallet?
So only a web browser is used, doesn't mean you cannot use it on a mobile phone, of course, but then it will just be a web application running on your mobile phone. So there's no native code required, but it also means that you don't have access to the, the security APIs on that platform.
But fortunately we have Fido, so we we're gonna use Fido instead. So the idea is to have a wallet.
So in, in the A RF for example, there's this notion of a a, a cloud wallet. So this is sort of a cloud wallet, except that it doesn't use an HSM in the cloud. It uses an HSM in your pocket, so a Fido security key. So we've built this open source software together with the Gnet and sunnet.
So, so we, we are in it to, to do the Fido part and we have a open source implementation. There's also an instance that you can play with, and we're using this in the, in the large scale pilot. So DC four EU and EWC. And maybe you've heard the news this week that we've also been selected as a cont contender in the unfunded track of the springy funke contest.
So that's something we'll also be focusing on. So you might wonder why a web wallet, well, basically to be independent of the platform vendors and, and why do we want to be independent?
Because it's kind of hard to assess the security of these platforms. So for example, on Android phones there, there are many vendors and well, if, if you need to have security guarantees about the protection of your, of your Raffi credentials, that can be very hard. Whereas in Fido, this is, this is a core feature of Fido. So you have this hardware at the station that has been mentioned, you could use that to actually prove that your RIF credentials are protected using secure elements that can also be certified.
So there's this Fido certification and other certification levels, and you can actually prove that some, a security key has been used that has been actually certified.
And this, this, that's interesting because I'm not sure if anyone from Czech Republic or Norway is here, because in these countries, fighter security keys are a notified EID. So the same security key that you may use to sign in today can be used to use a web wallet like this. So if you use it on a mobile phone, so we have a rendering here, this is what our demo instance looks like. It actually looks like, like a native app.
So it isn't, but it's something we call a progressive web app. So it's, it's a, an application that looks like a, a native app, but it's built using plain old web technology. And today you can actually do amazing things with a progressive web app because scanning QR codes, et cetera, that's, that's all built into this notion of a progress progressive web app. So we think that a web wallet is particularly interesting for some specific use cases.
Of course, exactly the use cases that we're focusing in in EWC, things like organizational wallets and the legal personal wallets.
So that, that is one of the reasons why a web wallet may be interesting, because usually the mobile phone is, is a personal device. And it may be a little uncomfortable to have your organizational credentials stored on a, on a personal device. So it makes more sense to use some something that is independent. Using a web wallet means that you can actually use the same wallet from multiple devices because it's just, all you need is a web browser, right?
So the idea is that your, your, your wallet contents is encrypted, either stored in your locally, in your web browser or securely stored on some cloud, but in an encrypted form, you just download it into your browser, use your security key to decrypt the contents and yeah, do do whatever you need to do some presentation.
It's also easy to recover from device laws because it's not tied to any particular device, it's tied to a security key, and you can actually have multiple security keys registered with the same wallets, so that also, so you can have a backup security key just by registering another security key, or you could maybe share a wallet with a coworker. And for consumers, end users, there's also this notion of inclusiveness.
So there, there's no requirement to buy an expensive, any expensive hardware, just use any web browser. And that might be relevant for, yeah, I mean the, the, the wallet has to be available to any citizen in the eu, so the less requirements, the better. So how does this work?
So this, this, I guess this picture has been shown many times. The, the only addition now is that this wallet is now projected with this Fido security key instead of the, the platform features of that, of that mobile phone.
Well, here it's a mobile phone, but it could also be just a desktop web browser. So the obvious way to use security keys is to authenticate. And indeed, if you, if you, if you have a contents stored on a web on a cloud server and you wanna download it, you need to authenticate using the, well, the Fido authentication that we've been discussing in, in this track to download your encrypted wallet contents. Except that now you can also use decryption using that same fighter security key. And I'll explain in a in a minute how that, how that works.
But the idea is you, so the, the, the protection of your wallet contents is tied to your Fido security key. So that's about encryption and decryption, that that's, that's not the primary use case of Fido, but actually not many, many people notice. You can actually today use this as well.
And then there's also the notion of doing a presentation towards a verifier. So you would also like to have your signing keys, your proof keys used on a Fido security key.
Now this is something that is not possible today, but there is now a draft web auth and specification that takes care of, of signing a little more about that later. So I have a short demo. It's very short because authentication should be boring, right? Because it's should have low friction. So this is a rendering. So this is just a web browser pointing to our demo web wallet. It's on demo dot ww wallet.org.
So that is the name we've, we've used initially and actually it kind of stuck, so well maybe we will rename it, but actually it's, it covers the, the content because it's, it's, it's really a web wallet. So I already obtained some credentials, but if I want to download, so let's say this is a new browser, I wanna download the contents.
I just sign in to the, in this case the, the demo wallet. And this is just a normal Fido authentication. I'm using my security key, enter a pin. And so these are my credentials. So nothing special.
You've many seen many damages like this, but it is notable that when I signed in there was a decryption key derived for my security key, and that was used when the wallet contents was downloaded to decrypt that content. And now I, you see that I have two, two credentials here.
One, one pit and one university degree credential. Well, let's use that university degree credential to sign into a, a verifier. So this is a demo verifier, I wanna apply for a job, but that's the, the potential employer wants to know if I have a, a degree.
So let's, let's do this. So these are a couple of demos. I'm using the bachelor diploma, no need to scan a QR code because it's just in the same browser. Here I'm selecting my diploma credential. So my name is John Doe and here I'm selecting the credential and towards the verify, well, this is a technical demo, so there's some technical stuff there, but this is presenting my academic credential to the demo verifier. And this is all derived from something that is stored on my security key in insecure hardware. So how does it work?
Maybe you've heard of H Max Secret, that is something that Microsoft uses. And when you, when you use a security key to sign into a Windows system, well, there's actually an equivalent in the web offense standard. So it's called the PRF extension. So PRF stands for perfectly pseudo random function. The idea is if you have a, some kind of seed and you, you send that to the security key during a web get, you could, you, you can get a random output, but it's reproducible. So every time you use the same input, you get the same output.
So this can be used to, to generate a seed for a key derivation. And that is what, what is currently used in the demo web wallet. So that means that this is used when you, you, you're authenticating to the, to the demo wallet. This is used to derive the decryption keys to decrypt the contents of your, of your wallet.
This is also the way to make sure that you can use multiple security keys to decrypt the same wallet content. So you can have a, for example, a, a backup security key.
So this is what we are using today, but I think we can do better because it does mean that, because the decryption keys are derived, so the decryption is not actually done on the, on the security key itself. So, so it's just generating, deriving a, a key. So we're working on some extensions to take care of this. So basically to do the, so, so there's actually two extensions.
One is to, for, for signatures and one is for key encapsulation. And these are now a, a pull request on the web off and specs, there's a link here. I have some resources on the last slide if you want to make a picture. And the nice thing is that this, this will have multiple applications, not just for a wallets, but there's a lot of interest in these extensions because you can have all kinds of other applications, for example, to sign documents, which is actually also a use case in the, in the, in the, in the EU wallets.
So this is a work in progress, but we have a, we actually have some prototype implementations of to work with this in the wallet. And we're trying to work with vendors to, to actually have this merged into the next version of the web off and spec. So there's an one other algorithm, this is a bit technical, but this is because you want to have privacy, you want to generate multiple keys at once. So this is another draft which is sent to the ITF.
This is, well, if you want to have un linkability, you will need to have independent keys. So this is a, a, a way to generate multiple keys at once so that you don't have to push your, the button of your security key multiple times when you want to generate multiple keys. So here's some links if you wanna have a look, if you're interested in the, in the drafts, there's a actually a rendering here, so you don't have to look up the, the source on, on GitHub. So there's a nice web rendering and if you wanna play with the, the demo, there's some links above. And then my time is up.
I think hopefully we'll have time for some questions.
Yeah, thank you very much. Just that was really interesting and
Yeah, absolutely.
Well we do have questions for the audience. I see. But may I have one short one from you?
So yeah, this demo, will it work for me today? What are the immediate product methods?
Oh yeah, very good question because there are some limitations, but, so the PRF extension that is implemented in, in Chrome, so if you're using Chrome on the, I'm not sure if it's works on Linux today, so I'm peeking in. Yeah, it works on, I mean on the Windows earlier there was an, I think you have the latest version of the web auth and stack on Windows. It will work on any, any platform with the Chrome browser. And actually it also also works on Android. So if you have an Android phone, so if you don't have a security key, you could, you could, you can use Android as well.
Okay, thanks.
So thank you for that question. Question. Okay.
Yeah, it doesn't
Work.
IOS doesn't work yet.
No, but hopefully it will eventually.
Thank you.
Hey Yos. So thank you for the demo. It was about the best wallet I've seen so far on this conference because for a simple thing, it doesn't break the media for the user. You don't have, if you sit on your desktop, you don't have to break out your phone to log in, which is a huge bonus for me as a user experience. I just have one question. You mentioned that the data can be stored locally or server side. Is that a user choice to use the browser's local storage or server side?
Or is it a deployment side decision done by whoever operates the wallet?
Well, so this is demo wallet of, right? Right.
So, so here we have it stored on the server so that if you move to on a browser, you can just download it from that server and then it's, it's stored in the browser as well. But of course if you, if you have deployed this for real, then you can make it, you can make, make it optional for example. So it could be a user setting.
Okay, please don't store it on the server, but that would mean that it would be hard to move to a different browser. Yeah. Or please don't store it locally, just store it only on the, on the server. So that is, yeah, so in our demo we do both, but yeah, that is very easy to, to change of course.
Great, thank you. Yeah.
Okay.
Nish, I believe we have a question from our online audience. Yeah. We
Have one online question as well as, you know, apple recently reached progressive web apps. Are you in contact with Apple about this or are we just bound to a normal web app on iOS?
So, yeah, so it doesn't work on iOS today, but yes, we are in contact with, with Apple, not my myself personally, but we have John Bradley here who is in contact with all the vendors and going to all the meetings. So I'm, I'm not sure if there's any latest updates, but,
So
The Apple employees do complain to me that it doesn't work on iOS, which is
Progress.
Yeah, yeah.
So do we have any further questions?
How, how does the backup and recovery scenario look like if you use a physical file token?
Yeah, so the backup is fairly easy because if you have the, the content stored on the, on the server, and let's say you've, you've used it, so lemme first are you, meaning do you mean the backup when you lose your security key or you lose your device?
If I lose my security key?
Yeah. So if the security key is lost, then I hope you have a second key, but know that you don't need a second phone.
Like, like, so if, if with a native wallet, if you lose your phone, then it's, it's considerably more harder to, to restore. So if you have lost all your security keys, you'll have to get your credentials.
So I'll add that you can back up. So you can have multiple security keys registered with the same wallet instance.
However, where you are going is that if you have some of those credentials at EIAS high, they would be bound to a single secure element. So if you were to lose that element, you would have to re-enroll, you would be able to keep the EI ds substantial ones credentials that were bound to potentially multiple secure elements.
But as long as, you know, potentially we can have some discussions around the arf and you know, if Germany were say, willing to allow issuance of the PI to multiple secure elements, which is conceptually difficult as long as, as long as it's only one at one time, then you pretty much gotta reregister if you lose that one thing. But, you know, there are ways around that, but we have to have some complicated discussions I suspect.
So.
So just to clarify the keys of my credentials, are they the keys on my hardware token or are they keys in the encrypted container that I fetch from the cloud and my Fido token keys are only the authenticator to fetch this encrypted cloud storage? Or is it maybe either of a
Right now it's, so, so the current imp implementation, the, the keys are derived from security keys.
So the, the signing keys are stored together with the, the credentials, but with the new extensions, we strive to actually have the, the, the proof keys on the security key itself.
W which is totally alleged in, in the session before, I think he said like 90% of things are easy and don't need high security and 10% maybe do need strong security. So I think having both is actually an advantage that maybe low assurance keys are on the encrypted cloud storage. And if you have a German PID maybe you bound it to the, to the fire token itself.
Yeah.
So I'm happy to discuss this later with people 'cause we're undoubtedly gonna run out of time.
But at the moment the master derivation keys for the individual verifiable credential instances are actually stored encrypted in the encrypted blob and the encrypted blob, the content, the encryption master key is re-encrypt by each of the keys that you, so it's, it's fairly standard cryptography and the reason why it works with multiple security keys on multiple devices is because the derivation, so at the moment the derivation for the indivi for each of the issued PIs, the seed is actually in the encrypted data.
Okay.
I think kind of to avoid going way too deep or into the technical discussions, let's just move the rest of this talk to the UBI o stand. Thank you very much Yost. That was a really unexpectedly long but useful and interesting presentation.
Oh, thanks a lot. Thank you.