Thank you. Thank you, Matthias.
In fact, it will not be the real business case. I will look at a couple of thoughts around different business cases that are more frequently discussed or less frequently discussed. I also can assure you that there are more than these.
Because, for instance, one of the panelists will look at another set of business cases or another business case. But I think, basically, to a certain extent, Nick Lambert, who is one of the panelists, is guilty for this session. He probably doesn't know, but it is. Because Nick triggered quite a number of conversations on LinkedIn about where's the money in that. And that made me think about, let's put this topic on the agenda. And I had a hard fight with our agenda team that they give me a bit room in the agenda. But finally, they gave up.
So, we're here with this topic. I want to start with a picture. This is the issuer-holder-verifier model. Probably most of you have seen it. Which is a bit of the foundational model of decentralized identity.
So, there's the issuer, to the holder, to the verifier. And then there are wallets, plural. Very likely plural. Not the wallet, but the wallets. And at last year's EIC, Pramod Varman, who was the chief architect of Aadhaar in India, said, keep in mind, we are issuing credentials to the holder, not to the wallet.
So, the holder should be in control. And we should have a certain level of flexibility. I think this is a very important aspect here because, yes, it's plural. And I had last year, in my opening keynote, I talked about a use case, which initially was a large-scale pilot use case in the UDI wallet world, but which became a bit shrunk down.
So, it moved from applying for a loan at a bank to opening a bank account. Opening a bank account is totally boring.
Yes, it doesn't work well in today's world. So, there's really a room for improvement. It could work, but it's by far not as interesting. And I talked about, you know, maybe the individual in the wallet has verifiable credentials about what they were named, derived from the passport, date of birth, address, employment status, the salary statements derived from, for instance, Germany from DATEV, whatever, more on the ID cards, the financial status from different banks, information about real estate, merit status, et cetera.
You would have everything there which we could use to inject into a business process and simplify all the AML, KYC processes, the loan sort of proving processes and save tons of money for AML and KYC costs. Unfortunately, as I said, it became a little smaller. But it's really also a lot of—the point I want to make here primarily for now is it is—we should think not in whatever—a little bit of verifiable credentials around. This is Martin, and he lives there, and this is his age. We should think about tens of thousands of verifiable credentials.
Then also the term wallet becomes a bit weird because we don't have 10,000 cards in our wallet. We probably have more things like folders or drawers or whatever. That also means we have different wallets. I believe strongly we need some more flexible approaches here. There's just a bit of a thinking also behind how some of these business cases only could work. I think it's important to understand that not everything will work in a model which is related maybe just to a secure element. I also had guests yesterday, a very interesting conversation with the winner of this year's Kim Cameron Award.
By the way, the clock, as usual, is not ticking down. That makes it a bit tricky for me to stay on time. But I see it's 10.37, so I know just 13 minutes left, and I'm already over. I'm far too late in my presentation.
Anyway, she's from Kenya right now, living in Rwanda. She said, we need something which works on a $50 device. Then we don't talk about secure elements anymore. There is no secure element, at least not today, on these devices. We need to have things that work better. But let's look at business cases. It might be a bit provocative, but hopefully it triggers the conversation in our panel.
Yes, there's the identification authentication signing case. We all know that. I'll go into detail. There's a sponsorship case that came up in a podcast I recently did with Nick. I forgot the other name. I'm very bad in keeping names. Identity management problems, I have to say. We have an issue verifier. Let's call it shared cost model. I'll come to this in a minute. We have micro or nano payments as a model, business enablement process improvements, and value-adding apps with wallets. These are six things I want to walk through very quickly.
What I used to, so to speak, have a bit of a rating for these. Sorry if I was too fast. I used a model from a management book, Blue Ocean Strategies, which basically looks at what you're doing. Is it in a red ocean, so with a lot of competition? Or is it in a blue ocean where you have more of an uncontested market space? It's very clear. This is from Kim Warborn, a professor from INSEAD, published quite a while ago. Where's the money? How do we create business value? Where's the uncontested space? What we are looking for, is this really an ocean, or is it just a pond or a puddle?
Which also might be the case. It might be uncontested but small. I look at it from this perspective, and all the slides will be available for download. Identification, authentication signature. How much interaction do we have with governments? It's not really much, honestly. How frequently do we interact with the government per year? Ten times? Fifteen times? Maybe. If at all. Depends on how we count. If it deducts the low assurance use cases, like I do something around getting the large waste being carried away, but I don't need a high assurance level, then it goes further down.
In the world of the broader use cases, we have a lot of identity verification players already around. I think reusability can help. There's a clear advantage. When you try nowadays in Germany to open a bank account online, and you go through this human-backed identity verification, and maybe you're married, so you want to have the bank account for two people, you do it twice, then you really don't like to do it again. It's horrible. It's a total lack of any positive user experience.
Yes, there's a market for that, but I think there's still, as I've said, a lot of competition. It's really more on the side of the Red Ocean, fierce competition. The benefits of reusability and trust will be understood if you communicate it well. In some countries, they are super well understood. If you go to parts of the Benelux, if you go to the Nordics, Estonia, et cetera, it's understood.
In others, it's probably less understood, like in Germany. On the other hand, we need to be clear that these benefits that are necessary are understood as a real benefit. When models work and we say, okay, I did it, and I don't care much about it anymore, I can come in where I want. What we must not underestimate, for most users, it's just pressing the finger or holding it here, and you have your single sign-on at the end of the day. We have something where we interact in a very simple manner with a lot of different services and feel comfortable enough in many use cases.
There's a competition also from that end. We need to be very clear. If we make it too complex, in any way, we will fail. High assurance makes sense where high assurance is really, really needed. But in most cases, we have maybe low assurance, medium assurance. Don't do everything with the focus on high assurance. We could also cynically say, don't let the people who come from the government side with this high assurance thinking drive the initiatives. Most of the use cases are not high assurance. The question of who pays isn't solved.
Sponsorship, I think for everything which is sponsorship, where someone is driving it, LinkedIn verifications paid by Microsoft or paid by your LinkedIn membership in some way, qui bono. Obviously, if someone sponsors something, there's an interest in that. We need to be very clear about it.
Clearly, there are some edge use cases like MDL in various regions. We have some models that work extremely well and that have proven to be successful. You purchase it for a good reason, but we always need to ask, what is the reason behind that? We also need to look at, is it sufficient for large-scale adoptions? That doesn't really make a business model out of it. It's more an enablement that you say, okay, if I have the critical mass, probably something working will evolve out of that. It's probably more about creating a critical mass here. That will be interesting.
It remains to be seen what is accepted to which extent. As I've said, once private parties are in, it gets tricky.
Still, I have rated more on the right side. Have you ever read this one? This issue-verifier model. This is not a business model. It's a shared-cost model. A shared-cost model is not a business model, to my opinion. If there's a scalable revenue, so you issue, take the risk, and for every usage, you earn money with it, then it would be a business model. Someone would need to come up with a very significant pre-investment and say, okay, I do the identity verification, then I earn my money with that.
If states or large companies provide verified identities for free, then it's hard to compete here. We need to be a bit careful. Shared issuance models sometimes work well. Some didn't work that much.
Again, some work better. I think shared issuance models can be quite interesting. Just saying, okay, if one bank says, okay, I have 1 million customers, the other has 100,000 customers, then it's very likely that a larger bank will issue approximately 10 times as much verifications than the other bank, so it will be fair overall. That works, by the way, well. I always think when it comes to these shared models, they say, okay, I do my part, you do your part, and at the end, it will be probably pretty fair. Look at the World Postal Union, 1875. It has proven that it works.
But we would need a micropayments approach or even a nanopayments approach, an approach which is really working with very, very small payments. There could be some interesting use cases derived from that. For example, sharing healthcare data to whatever clinical trials.
Okay, it's one of the use cases where sometimes you say, okay, this is the best one. But we could think about paid cookie consent. Sounds weird, but if you get rid of cookies the way we use it and say, okay, for a certain use case, we do that. We build a concept 2011 life management platforms. I still need to update it. So there are ways where we could have repayment models behind it and clearly paying for the users' verified identities for the sake of authentication. But it would be really very, very small amounts. We would need to have the right things.
And a bit of food for thought here around the consent. Verifiable credentials potentially can carry consent.
Nowadays, when we do cookie consent, we immediately forget about what we consented to. We don't even understand what we did. If it's in a contract, if it's accessible or mapped to a distributed ledger, we could see what did we agree to, for which purpose, which period, to whom. We can revoke it. We can handle it very differently. We could potentially even make it with a user interface that a normal human understands. That could be a very interesting area where a lot of these things come together, where different technologies play together, where we can do some really smart things.
I talked about the business enablement, and I'm running a little out of time. Process improvements. I think currently the lowest hanging fruit for what we have for now is everything where we improve business processes, where we reduce process cost by injecting verifiable credentials into processes. This is what the business understands. I'll take my example of KYC AML costs. A large bank pays hundreds of millions per year in that area. If we can reduce that, we have a business case.
We don't care about who pays for verification and issuance because the bank is interested in saying we get the cost down. There's such a clear business case, though, that we don't care about the rest anymore. Let's think about the big business cases, not the tricky small ones. This is where the money is, and there are a lot of other samples around that. Then there's one other thing I'd like to throw in. It might be that we make the money via apps. I think Daniel Goldschneider yesterday said, if you can get rich with the wallet, then something is wrong because then you have monopolies, etc.
Think about wallets. Think about services that integrate these wallets that also can bring in other ideas like passports. Passports are very global, available, verified identity, biometric passports. They add things like privacy, connect data between different things, connect to other areas, share fiber conventions. Then you build applications around it. I yesterday talked in a panel about my travel experience to Austria. If there's the Austrian travel app, if there's the health app, if there's the finance app, that is where you can do a ton of things that benefit from the wallets.
The wallets are just the means, but then there's the business model on top of it. This is, I think, where things really become interesting. Going back to my opening keynote, maybe there is also trust in standard identity management use cases in the enterprise or for consumer identities. The point that we finally get to a verified identity we can use instead of dealing with all the complexities of handling identities and directories, etc. That was something I covered in my opening keynote.
Not much time for all these ideas, but we have 40 minutes for a panel to dig deeper here into that conversation. Any direct questions or maybe we handle the questions on the panel?
Matthias, you're the moderator. No direct questions from the audience right now. Are there any risen hands right now? No. I would run with a microphone otherwise. Here's one. Okay. Take it now or move it into the panel? Maybe we take it as the gateway. Or that segue. I liked your idea on business process, but the example you chose was a heavily regulated space. Maybe you can speak to that a little bit more. Looking at this, a lot of it felt like it was a marginal use case, but this one is compelling, but it's also high risk. Maybe you can speak to the verified credential component more. Okay.
I think a fair point. I think we can take that into the panel because that is an important point where two things come together. How good is the verification of the credential? And how much change do we need from a regulatory perspective?
