So for those who dont know me, I'm Mann. I'm one of the six founding members of the fire line. So everything you have seen, just the file specification, blame on me and my colleagues working on those things. And what I want to talk about today is really how I think past keys, pa key providers on one hand side and wallets come together in the future. This is a interesting merge or convergence I'm seeing as it's, let's start with some history. Fighter is all about authentication. And in my presentation I really talk about authentication in a narrow sense. It is recognizing it's still the same.
You, right? So you have created an account, now we you return the next day. And that is things we do multiple times a day, right? This is what I call authentication. We know my passwords are mostly used today, I would call it as a 90% use case.
We have MFA already 10% use case in my opinion if you count right? Don't really look too deeply into those numbers, but they're good indications in my opinion. So MFA used 10%.
The challenge we have all seen, and I won't go into details of that, is bar tokens are subject to men's middle attacks and phishing and authentication happens multiple times a day, right? So we all see a lot of those kind of fraud protection points. So what can we do? We looked into authentication, that's what we did with Fido and we started 12 years ago and found out that linkability is important, right? You do not want to have correlation handles deeply baked into the authentication protocol. You want phishing resistance.
And to be honest, we want phishing resistance a hundred percent of the cases, right? Even though we are not having that in, in any case today, mainly, at least not on a scalable level, we understand that cryptography is needed to some degree for everything which is remotely done and needs to be secured for that.
And we need to define security levels roughly in 10% of the cases and 90% of the cases the security level, yes, it needs to be good enough, but you don't need formal proofs and, and a lot of inside into the real security for that. So PA keys provide that.
That's exactly why we created those. They provide the phishing resistance, they provide the unlink ability as well. And so you could sing. Now all is good, right? In reality during our journey with Fido, we learned that people have multiple devices and that's easy to do with passwords, right? You just enter the password on any device. So it doesn't really matter too much. It's a high price. We pay for that. That's fraud. It's spaghetti on the, on the server side to mitigate all the, the, the challenges, the risk side security problems we have with passwords.
But if you're moving to something which is key base, now we have to implement explicit measures to support multi devices, right? Keys do not exist on all devices. They typically start on one device and now you have to think how to carry them over and what to do. What we did in Fido is essentially supporting two different concepts here. The first is what we would call cross device authentication. You are have your key on one device. Now you use that key on that one device to authenticate a session on another device. Fido cross authentication.
The key does not migrate to the other device, it stays on that device. And you can do that for each authentication separately. If it's a kios pc, that's a, a good way to do that. But you could also say, okay, now it's my tablet really and let's do it once and after that I create yet another device bound key on that other device.
And it really works for device bound key as well as syn pass keys. So it doesn't really matter. This is how you bridge gaps and from different platform families to another one.
But if I really want to migrate permanently to a new device, that's not the the best approach we can take, right? The other approach would be, okay, let's make sure we can move the key from that one device to the other. That's this pass key. And in essence, that is exactly what we need to effectively address the 90% use case to replace the passwords, right? The MFA replacement you can already do with the device bond keys, but the 90% use case, the password replacement only works if you have an effective way to hide device boundaries.
And this is one of those ways to hide the device boundaries to make them virtually disappear.
They still exist physically, but yes, they're virtually disappear. It's easy to use a key on the other device so you can authenticate via another device if you bootstrap that new device, right? If you still have the old device. But if you do not have the old device, and that's interesting observation here, right? This is where remote identity verification comes into the picture, right? So if you take a new, unpack a new device the first time, what's the first thing you do?
You somehow have to tell that device. You are now my device. If you still have the old device, you could do something with your old device, do that. If you do not have that anymore, you lost stone, whatever, right? Now you have to do something. And that's what I would call identity verification in the broad sense, right? It could be as simple as sending you an email, make sure you have an access to that email address.
This is the the low end version of identity verification in my opinion.
But it could also be the high end, like what banks have to do where you have to verify it's government regulated, right? It, it has nothing to do with an anonymity anymore, right? You have correlation handles, you need the name and that's a legal obligation to get all that information. And this is really interesting to see that because this fast identity online Fido right? Is the first time where identity really gets into the picture right? Before that identity was kind of out of scope if you will, right? You could do any kind of identity binding in the first place or later or never, right?
Depending on your needs. With that, we, we really feel this is coming to Fido and this is why it's fi fast identity online and not fast authentication online only. And so with that, this is my first convergence driver that I see really it is with paske providers, we make it easy to migrate credentials over to a new device, but we also need to perform identity verification. If all devices are lost in stone and leveraging verifiable credentials doesn't work, right? Those don't exist anyways, right? This not yet, right? So this is a bootstrapping thing.
We have to think about that Paki providers address that with Fido. We are all on that. This is why we have synchronized or sync pass keys here.
Now what's the user benefit? If I have roughly a hundred accounts, I think that's the average today or in that order at least, right? What would I do? I would've a single gesture, right? A single action for me to migrate all my a hundred credentials over to that new device. Where today that is something I have to do per account, right? With all the device bound keys, it's a one per account action.
It's a hundred different things and it's really painful if you look at the, the high security accounts like bank accounts where you might have five or so, right? It's five different actions and that's, that's, that's a pain point for the user. So one step per device to migrate all the pass keys and that's great. That's exactly what we want. Okay? Now this was the authentication side. Now look into the wallet side, right?
We now look into the, let's call it the 1% or 0.1% use case where I create a new account, right?
The I authenticate every day that the 99 at least use case might be even more, right? But sometimes I create new accounts and I didn't talk about that really. And Id proofing is required here as well. In the broad sense cloud storage providers don't care really given email address. They're done right? Us a cloud storage account. If it's a bank, it's completely different. And now I have to share the things in practice, I mostly have to share email addresses, sometimes payment guarantees.
Rarely I have to share other verifiable credentials or other information attributes like my real name, my real address, right? Endorsed by the government. Those things are there and today it has to be done once per account. If I create one bank account, they, yeah, send me through some kind.
In the past it was go to the branch office, now it's remote. The safety plus picture ID typically or video ID or whatever. All these kind of things which are kind of annoying, right? Take a lot of time and not nice procedures. It could be the national ID card in Germany, at least theoretically, right?
It would, it's underutilized. It would be great tool for that. And it's so much more convenient.
So for me, this is an opportunity, right? Where today we lack the usability, it's not great and we lack robustness of the security as well, right? Because this is where the DeepFakes come in and help you break those systems and it's difficult to, to prevent those. So wouldn't it be nice if we would have issuers which would issue me those credentials And that's exactly what the wallet ecosystem tries to do.
Have those issuers which give me those credentials so I can use that credential and have a one IDV identity verification procedure per verifiable credential at most and maybe even use those to bootstrap another issuer, right?
And, and let them do things on top of that, but really reduce the complexity to create accounts. So this is the thing which we're really trying to address here. And now if you think about the real use case where it's not just boarding passes that we want to share, we need really a key for whole binding holder binding, right?
This is where the cryptography gets in again, right? Everything remote needs to be secured. We need crypto here, right? Nowhere around those. So it's really one IDV per issuer per verify credential. That is the benefit as opposed to one per account, right?
Again, the a hundred accounts I have right now, I have it to do it once and not a hundred times whatever, depends on the kind of attributes I want to share, right? But at least the email addresses. But no wonder right now that we have the key, all the different things, the observations we had in Fido will apply here equally, right?
So yes, there will be cross device use cases that we need to address and if you remember and the IAW right couple of weeks ago where people showed that, right? Using Fido, right cross device or sending all hybrid, right? The cross device authentication protocol. And for me this is a convergence driver number two, right? It's not only from authentication to wallets, it's also from wallets to look into pass keys, right? They are use cases that you need to address in the wallets, which are already solved in the fighter ecosystem using pass keys.
So look at those, how we solve them and maybe there is a way to leverage those. Number two, as a convergence driver, this is cross device. Now we have device migration as well, right?
No wonder, right? I I change my device or devices every two years on on average. So I need to permanently move all my verified credentials over and especially the key for the holder binding or the keys for holder binding depending on what kind of crypto we use for that and how that works with post quantum in the post quantum world.
So convergence number three really is wallet providers have to back up and restore keys and guess what, right? This is already been addressed with past keys. So we have that maybe just leverage what we have there and that makes it a single step per device.
An issuer to make, migrate all the verifiable credentials as opposed to having one step per credential or one step per relying party even right? To do all that. So that's a a a lot of savings here In addition to that. So another topic, key protection, right? If you issue those sensitive credentials or meaningful credentials like government, right?
What, what you have on on a national ID card today, the security level is relevant for the issuer. They won't do that to low security things and especially Germany has very high expectation on that. And user gesture classes, like is it a user verification?
Is it just a user presence check? Is it nothing, right? Are relevant as well. So you get into static attributes and dynamic attributes which you need. So you need attestation convergence driver number four for me. You need some form of key attestation here for the wallets as well. We have that in the Fido world.
Look into those that meets an A supporting infrastructure around that where you have metadata where you understand how to do that. Number five, right? You need verifiable user consent. We heard user consent is dead. I think yeah, maybe theoretically, practically you still need it, right? So if I want to move $10,000 from account A to account B, my bank needs something from me. It's definitely not a contract that I sign, it's just a something I want to do and and approve.
But the bank needs a, some kind of indication evidence that I've really seen and understand what I'm trying to do and that they can later tell me, yes, you really did that right?
It's not an a mistake on our side. So this applies equally to sharing health data and other data. So it's not only about the credential you want to share, it's about the thing you would do after that as well, which is for me, convergence from driver number five. So you have to get into that, that is relevant and will apply to wallets equally as it applies to Fido. And that's where we have activities in Fido.
It's called confirmation there, poor request open there. We have addressed that in some protocols, not in in all other protocols, especially in the browser. And ideally you have trusted UI backed implementations in the long run. And that gets me to another interesting point. Wallets today are just big amorphous apps, right? And big and amorphous is the enemy of secure, right? We all know that. We have learned that.
So what we really need is a security kernel, right? And this is something we need to think about as well plus wallets today is the software side of the house.
It could be a cloud-based wallet, but it could also be a national ID card, right? Like external hardware. If you look into those, you need to think about what kind of functionality provide in those, in this kind of security kernel. And I would argue you need to talk about key protection makes that transparency. Relying party user verification, the attestation and the confirmation display and the security level of all that where maybe the confirmation display is an optional thing in the, in the external hardware.
But that's something you need to think about and from that perspective, and that is convergence driver number six for me. The last one I want to share today, right? Look into fiber ecosystem.
That is what we call the fiber authenticator, right? That's already there as a concept which has all different characteristics from static two dynamic attributes at the station and all that, right? And security keys if you do that outside when where we want to get support for the for the confirmation display and other things as well. So authenticators should be leveraged there.
And that is really my summary here. You need identity verification to restore pass keys. You need cross device use cases, backup, restore keys. You need a station, verify the user content, you need a security kernel. And by the way, you need a web API and default implementations to really scale because users are not in the business to download additional apps, right? For any any reason. And that's what you always see to get adoption, there must be a default implementation which just works.
There will be a small percentage of users which want to use their own, but to really scale it, you need the default one. So this in my opinion is what I want to leave you with. We can leapfrog froog a lot of those wallet adoption topics and especially the security and how to get the security into real world implementations on real devices because this is what we have done in Fido and that's where I think look into that and maybe leverage just Fido authenticator as a concept inside wallets in general and help us to get adoption there to, to get more secure implementations.
The practice because Fido implementation is already, does already exist on all new devices which are shipped today. And that is a great accomplishment. It took us 12 years to get there, right? Leverage that instead of reinventing the wheel here. Thank you very much.
Well thanks a lot. I guess any questions from the audience?
Hey, I agree with most of the analysis that you did and I think a lot of people in the wallet ecosystem would acknowledge them as well. When I compare the wallet ecosystem with Fido, I would see that Fido is a two party model while the wallets and verified credentials are a three party model. And I see a lot of security measures in Fido for privacy also that make sure that one key can only be used for one relying party. But now we also have an issuer, so we would need to use keys for more than one relying party.
And I think there's kind of a basic contradiction between the three party wallet ecosystem and the two party fighter model I, and it's kind of baked in into the core of Fido. So how do, how would you want to solve this?
So if you look at to the fighter attestation, that is not really a two party model and it's already there to help relying parties and the vendors of the security keys, right? To get something. So we are get, we are already having a three party model there. It is just called at a station and we use it for different purposes.
But I agree the scope of the keys and the use of those keys need to be discussed. But for me those are smaller things where all the big things, and the mo, the biggest topic in my opinion is how to get actual implementations in actual devices, right? Like smartphones, the security keys are relatively easy to change, right? Smaller companies work on that. But in order to to change an Apple device or a Google device or Microsoft device, right?
Or, or the OM devices on that, there needs to, a lot of things need to happen, right? And that is where we have worked very hard to get the right abstraction layer in my opinion. And for me think about that and let's talk about the specific additions or changes we might need to do to really support the new wallet use cases where we have this three party model. But thanks for that comment.
Okay, great. Well thank you very much again.
