As one of the winning presentations from the pre-conference Blockchain ID Innovation Night, Dr. Torsten Lodderstedt will continue his presentation about the limits of Blockchain Identity and the challenges that still need to be solved.
KuppingerCole's Advisory stands out due to our regular communication with vendors and key clients, providing us with in-depth insight into the issues and knowledge required to address real-world challenges.
Optimize your decision-making process with the most comprehensive and up-to-date market data available.
Compare solution offerings and follow predefined best practices or adapt them to the individual requirements of your company.
Configure your individual requirements to discover the ideal solution for your business.
Meet our team of analysts and advisors who are highly skilled and experienced professionals dedicated to helping you make informed decisions and achieve your goals.
Meet our business team committed to helping you achieve success. We understand that running a business can be challenging, but with the right team in your corner, anything is possible.
As one of the winning presentations from the pre-conference Blockchain ID Innovation Night, Dr. Torsten Lodderstedt will continue his presentation about the limits of Blockchain Identity and the challenges that still need to be solved.
As one of the winning presentations from the pre-conference Blockchain ID Innovation Night, Dr. Torsten Lodderstedt will continue his presentation about the limits of Blockchain Identity and the challenges that still need to be solved.
For identity. I think it's an interesting question. Whether it's the one thing which won't help or might make a lot of things better or make everything better. So curious about your use, please welcome Dr. To So good morning, everybody. I'm Torson I'm the CTO of yes. Dot com I've been developing and running a large scale consumer identity management systems for about a decade now and also a contributor to the, or, and open connect working group.
We at yes, dot com built a identity scheme for banks and their customers, which allows their customers to identify themself and electronically sign legal documents. And as part of my, of my job, I'm constantly seeking for improvements in our technology and over architecture, which leads us last year to move from a centralized proxy based architecture to peer-to-peer distributed architecture. And the question was what's next. And as we all know, and we have heard about that here at the conference, blockchain and self-sovereign identity are hot topics these days.
So my team and I also took a look into the topic and I would like to take the opportunity to share our thoughts and insights about that. And I'm also looking for your feedback to clearly spell that out. My perspective on, on, on blockchain technology is that of a professional software engineer trying to solve a real business problem. So I'm looking for technologies that help us and our partners in the short and midterm to make our products better before we dive into Sessor identity.
And, and also what yes does, let's start with something that we all are familiar with today. Identity providing typically means there is a social IDP and the social IDP is used to log in, in various science and to provide attributes about us users, basically social IDPs, solved the registration and fulfilling problem. They've got a tremendous reach. They are easy to integrate and they are convenient to use. That's what they do, But there's a drawback or several of them.
First of all, a social IDP gathers user data because that's the fundamental of their business model and they are able, and that's an abstract threat to lock a user out or even a relying party. What's important for my perspective and the use cases I'm looking at. They don't have the sufficient data to really perform regulated activities, such as opening a banking account. So we are seeking for something that solved those problems.
So let's take a look into self self-sovereign identity because it completely changes the model users interact with services, the users in the center, and has the control about all the credentials and the relationships to the different relying parties and the claim issues. So you, as the user carry your credentials with you, you are in control while you use which credentials and the claim issuer is unable to monitor what you do with those credentials, which greatly improves non Correl, relatability, and privacy.
So there is no censorship in this, in this model, no big brother, no correlation, which is great from a privacy perspective. And by the way, it also supports offline cases, which is even getting even more important in the future.
So point of sales transactions and so on, because the boundaries between online and offline valid were, are blurring self-serve identity based on blockchains means that the blockchain is used as an immutable storage for storing identifiers relating those identifiers to public keys, storing metadata, such as D IDs and store public claims, as well as hashes of private claims and the private keys and the private claims. And those are the, the relevant data, which are really privacy, sensible are stored off chain. So that's basically what's, what's being done in, in most of those solutions.
So in the end, the blockchain is used to substitute the existing infrastructure of certification authorities, time, stamping authorities, and so on building a so-called dis distributed PKI. And in the end, the uniqueness or the selling point of those approaches is that they rely on the proof of existence that's built in, into every blockchain, the transparency about all the changes that are going on, the temp proven audit trail and the independent validation of all the changes. What are the question marks that we see with regard to self serving identity and blockchains?
So let's start with the obvious one. The user has to manage all the relationships to all the relying parties and to claim issuers, meaning the users ending up managing hundreds, if not thousands of relationships and the respective key pairs, I guess that they took a look into my password manager. I've got 250 user accounts right now. And that's increasingly, and the question is how is a, the average user able to man to manage that just for a moment, imagine that your, your wife, your husband, or your mom or dad should work with such a solution.
So this is a, a really a UX challenge that needs to be cut with next point, since you are in full control as a user and you store the credentials what's gonna happen. If your smartphone drops on the floor, this effectively means you lose your private keys. So you lose your proof that you are the legitimate holder of all the claims that you have to, that you have collected. Let's talk about performance.
I mean, if you want to go must market, then we're talking about billions of users and the transactions that they cause. And if you take a look under the throughput that public key chains offer today, you see there is a huge gap that needs to be, that needs to be covered. And it's even more complicated because that's just the average throughput, because the average time it takes to create a block is about 10 minutes. Which means if you wanna, if you wanna store a transaction at a block, it can take up to 10 minutes. If you're lucky to really attest the respective claims in the blockchain.
And it also depends how much money you are will to, to pay for actually attesting these transactions. Right? So the model in the end that we see today and solve sales, sovereign identity based on blockchain is rather static. So you go to a claim issue, you obtain a claim, you store that claim and you will use it later on very much later on, but what about dynamic? So if you wanna, if you wanna, for example, your mobile network operator attest your location to relying party in a verifiable fashion.
So if it takes 10 or 10 or 20 minutes to in the end store, this, this attestation, the blockchain, you might be in a completely different location. And there are other aspects like the balance of your, of your account, your credit score and so on. So in my perception, the model needs to be tweaked to really also support those, these kind of use cases.
Let's, let's talk about cost. I already mentioned that depending on what you are real to pay, you can accelerate the time it takes to manifest the attestation of your claims in the blockchain. So the question is, first of all, can we come up with a predictable costs for managing identity in the blockchain and who is gonna pay for that?
For my, for my experience in the field of identity management, I have no doubt users won't pay ascend for that. And as a last question, how does billing work? Because the claim issue wants to make money based on the claims it's being ATEST, but in the world where the relying party and the claim issue by design do not know each other. And there is no central authority, how shall settlement clearing and billing work. And there are two more aspects that are very relevant for the successful adoption of Salesforce and identity. And one of them is reach.
So if I, if I do, if I talk to, to relying parties on a sales pitch, one of the first or one of the first questions they ask me is how many active users do you have because they want to, they want to utilize the existing reach of active user accounts to improve their conversion. So it doesn't matter how good your onboarding process is. And if it only takes 90 seconds, if there is an onboarding process and you are starting from zero, then you're in trouble because you won't find relying parties that adopt your solution. And if you don't find relying parties, you won't find users.
And that's a typical hand and act problem. Everybody should have in mind when building an identity management solution. And there's another aspect that's not being addressed right now in such a network. How do I know which of the claim issuers is really illigible to attest that I am Torson L that born than Isla in 1971 in a way that I can use that for regulated transactions, such as buying a prepaid SIM card, opening a banking account, and so on. This depends on jurisdiction, the legal framework and so on. And I don't see a concept for that right now in the SSI space.
So there is a need for this kind of framework. And if you're looking for a short and midterm solution, as we do, then you will probably end up with something different and what we are looking into. And that's what we are building our ID schemes, and the difference between the self-serve identity approach and the ID scheme approach is self-sovereign identity is about self-constructed identity. Whereas identity schemes are about leveraging existing identities that are maintained by organizations or companies in, in several sectors for further use cases.
And, you know, the scheme approach from the, from the payment area. So who view as a credit card, please raise your hand. Okay. So you know how MasterCard is gonna work, and it doesn't, it doesn't matter which bank issued you the card. And that's because there's a scheme. So there is a common set of rules that defines how a MasterCard is gonna work. And it doesn't matter which bank, which bank you have, have a, have a business relation to and identity schemes work, work similarly.
So there is a common set of rules, and then all the organization participating in this scheme, more or less team up and build a virtual IDP. And there are several examples of, of these kind of ID of IDPs of ID schemes. One of them is mobile connect, which turns mobile network operator into IDPs. There is IDN, which is a ID scheme in, in the Netherland, which had been built by banks and also provides verified. There are some more in, in, in, across Europe and there is yes.
So the scheme and company I'm, I'm, I'm working with, and those schemes address both challenges because they directly offer you the reach, the existing reach, the customer base of either the mobile network operators or the banks behind them. And they are built on, on a trust framework. So let me, let me just a bit elaborate how we do that at, at yes.
So yes, is, is based on a peer-to-peer architecture. So there is no central central point of failure or big brother. So what we do is we turn every bank into a IDP and in the end, it's the user that controls which bank, which IDP, the reliant party talks to when it comes to, to a certain transaction. This allows us to leverage the existing reach of all online banking, user accounts of all the participating banks and all those online banking accounts have two very important properties. The first one is they all are backed by KC validated data.
And the second is every online banking account has two factor credentials, and it's getting even better in the EU due to the pressure by the payment service directive two, because it will lead banks over the forest banks to even more improve their authentication mechanisms. All those mechanisms can be directly delivered and be used by relying parties. And you may be wondering about the, the numbers in bold. This is just an indication of the, of the reach in millions of users for Germany, which is 50 million, the European union, which is 220 million.
And then the global scale, which is a billion. And this all is governed by a trust framework, by an existing trust framework of the anti money laundering law, because all the banks are obliged to interior, to the rules of this framework. And what we did is we defined the mapping, for example, from this trust framework to E Ida. And we can show that if a bank really complies with the AML, then we can directly create qualified electronic signatures in compliance with the eiders regulation, which are replacement for so-called wet signature.
So the, the typical signature you, you, you do on a, on a, on a paper trail. And this means that based on this approach, users can directly identify themself and conduct trans use cases that are really higher level and valuable, such as open a banking account, signing up for a prepaid mobile subscription or electronically signing a contract. And this is, this is really huge. This is a game changer. We've got challenges that we potentially will solve using blockchain technology. It's not the at adaptation part for the, for the users identity.
But's about the trust management in the network, because the challenge we are facing my team is facing that we have to manage the trust among thousands of relying parties on one side, and also thousands of IDPs on the other side, because allow, just, just give you a number in the European union. There are 5,500 banks, which means that in the end, you will potentially see 5,000 or 6,000 IDPs on the right hand side. And the question is, how does a relying party know that the IDP on the other side is really a legitimate IDP?
Because what, what can happen is that an attacker successfully introduces a new IDP into the ecosystem, which in the end acts as a fishing site for a certain number of users. So we need to prevent that that's a major threat right now. We are managing this infrastructure using traditional technology. We have all the security controls in place. We have all the trails and so on, but what I think is we could use a blockchain and we could utilize all the advantages. I just illustrated the temp proof audit trail. The distributed consents mechanism is a kind of a, of a additional validation.
If you wanna change something about our trust relationship. So building up a distributed PKI, that's something we, we will be evaluating in the, in the upcoming month. And there are other use cases that are very relevant in such a scenario because out of this 5,500 banks, a lot will merge or will be sold or bought in the upcoming next years. So what's gonna happen if an IDP goes out of business, because it's, it's bought, then we have to somehow migrate the user accounts. And we think that blockchain technology can help us to really implement it in a secure fashion. I think that's it.
Thank you. Wonderful. And I think it's very much in line with a lot of what we heard. So blockchain's not a silver bullet, which full of everything, but it's something which will help us do a lot of solve various challenges better than we could do without it. I think so. Yeah. Yeah. Without having it really implemented, but that's, that's our assumption. Yeah. Yeah. So let's have a look at question. So we have one and I think it goes in the same direction.
So the questions, MRI, and assuming that it will be a combination of existing protocols and maybe also P2P stuff and other things yeah. With blockchain that will make the future of KYC. Yeah. Yeah. Might be the case.
I, I don't know exactly, but yeah, it's a promising direction. Yeah. Okay. Perfect. And so with KYC, we also probably have to sort of low hanging food in the business cases for blockchain at entity, because that appears to be one where, which is painful to everyone, which is costly to the banks, which is painful to the customer and what we should Look at, we solve a user problem and we make monument. That's Perfect. And that's a good combination. So thank you very much again, applause for, thank you, Dr. To.