The Decentralized Identity Journey has Begun in Financial Services

Thank you everyone for coming by. We really appreciate it. We're gonna talk about how decentralized identity is gonna be implemented in financial services today. As you know, that's a main major theme of the show here at the conference. And so we're gonna go through an actual implementation planning stages and understanding in architecture and how it might actually be implemented in a, in a banking environment. One of the challenges that we have with federation, which is the bow wave that we've been all been surfing for many years, is that it has a big challenge around privacy and consent, doing consent management well and being able to have the privacy be in a, in a fashion that we can all be comfortable with as users. The other thing is that every time you add a new connection in the back end, so if you try to connect two systems together, you increase your attack surface, the, the, it becomes an A vector, an attack vector for hackers to take advantage of.
And finally, now that we have the EU Digital Wallet initiative coming here in Europe, the federation's not conducive to really future proof us to support that. So we need to start looking at verifiable credentials. This is the world that we live in. This diagram here illustrating that users are interacting with applications through intermediaries, which are called IDPs or IAM systems, for example, that sit in the middle and negotiate and share data on behalf of the user. And in today's model, we're as users, we're really peripheral to the transaction, right? We leverage these trusted third parties that are involved in the transaction and share the data. We don't really have insight all the time into what data's being shared or how much or how little in the transaction. And the, the goal is to move to a new model where the user becomes the center of the transaction, a user-centric model, and make the user a trusted first party to the transaction. And by doing that, we now can give the user the ability to have much more choice, control, and consent in the transaction. And the other great benefit of this model is that it's highly scalable. You can empower business partners and other affiliates very quickly without building all these backend integrations. So that means the users' identity and information that they need to share out can be shared in many more places, giving the user more power and and achieve more benefit.
So March 20th, ping Identity launched Neo, that's our decentralized identity solution and including very standards based model. We've incorporated some of the key standards in the industry. We'll be adding more in the coming months and and quarters. And our goal is to really have one of the most robust platform module centric approach that can support a lot of different standards. It's gonna be very similar to the early days of federation. We're gonna have lots of standards for a while around the credentialing and even different flavors of standards. So making sure that the user's experience is transparent and not have to worry about this is really critical to ping strategy.
So by getting rid of these third party intermediaries, you're able to have now the issuer issuing out credentials that represent a lot of different things. We'll talk about that in the next slide. You have the principle or the user that's receiving those credentials and then they're presenting them directly to the resource that they want to get access to. So what's in a credential and what can it be used for in, in a generic sense, it can include identification, enable identification, the person's identity. It could include a photograph, could include a passcode, biographic data about that person. It could be representative of their eligibility. It can incorporate attributes that represent entitlements or permissions or privileges that the user should be able to exercise. And finally, also purpose. Why are they here? Are you supposed to be here today? Why are you here? What project are you working on?
Right? Can also be instantiated within the credential. Also a person's affiliation. Who's gonna stand behind you? Is it your employer? Is it your bank? Who, who is going to be your backstop for this transaction? And who's standing behind the information that you're presenting? That also includes membership, customer status, and also roles that you might play with that organization. And finally, extended attributes. Where and when can the credential be used? Could be included in the credential, the policy details, the account information. It could be in the case of financial services for insurance. It could be your copay and how much deductible you have left on your insurance policy. It could include the account status and even balance or it could include your credit score in being able to present that as well. And with that, we're gonna now dig into a very specific program and project that Yarn is focused on and leading at Refi's and Bank. And he's the principal architect there. And I turn it over to you.
Thank you Daryl, and thank you all for coming. And as Daryl said, it's such a huge playing field of use cases and opportunities. And as Dr. Daniel Gold said on the first day, everyone comes to this journey with a lens and we came with a specific pain point. But as you enter it and you start learning and discovering and exchanging, we also learned about additional use cases that could benefit. So when I joined wifis and Bank International or RBI some two years ago, they took me through onboarding and orientation and I saw, okay, 17 million customers in 12 countries. And I told my own border, so we are, we're a banking group of a considerable size. And he said, no, no, we are not a banking group. We are a group of banks. I was like, what's the difference? He says, well, each one of these banks has their own technology infrastructure.
Even the products are different, but becoming a banking group is definitely what we want to do. Like wouldn't it be great if they develop a wonderful mortgage granting app in Hungary and we could deploy that across our subsidiaries Or someone comes up with a great process, how to give loans to businesses and we could take it from the original country and deploy it all over the place. Well, great, but the technology is all different. And IAM is just one example. Each bank has its own tech stack and each bank is responsible for their own customers and their relationships. I said, how are we gonna do that? And they said, okay, we got to get our application infrastructure standardized and homogenized. So we're gonna put standardized APIs, events, data taxonomies. I said, great. What about login? What about authentication? How are these users from the different countries gonna log into these central applications?
And then they looked at me like, oh man, we didn't think about that. I said, okay, in practical terms what's happening? I, I spoke to some applications and learned that basically every application up there at the top draws its own wiles to each country. And I looked at that, I said, that's terrible. That's, that's spaghetti and that's carbs. You know, it's not good for your diet and, and whatever you're gonna do here is not reusable. So, and and, and you'll waste so much time and energy and if you are successful, that's another problem cuz they end up with 12 different token polymorphisms. Good luck to our super talented central reusable API team on trusting 12 V worlds with 12 different token formats. Not even all of them jots. And I said, well what would you do? And I said, well I would put some federation solution in the middle and that's how I met.
Ping did this product and everyone was, oh, and then he said, oh, you're an architect. How would you like to be product owner of customer? I am said Okay, I'll build it. You have four months to go live. I said, okay, two of those months are July and August. They said, thank you very much, you know, but okay, I'll, I'll, I'll take the challenge. And and we did it and everyone was happy. And by everyone I mean the web applications, the mobile apps, they didn't like it. They have unique challenges when you consider mobile authentication. So if you're downloading some app and it does open, ID connect using all four native apps, that works fine cuz that uses, you know, the IDP of the platform. You don't really feel the browser as a pain point cuz you're always logged in with a cookie. You basically jump directly to the consent flow.
So that's fine. And if you are one bank and you have one app tightly integrated to your idp, that's also a great experience. But in our case with the federation and we are like an ecosystem of banks, that doesn't work so well because with PSD two we are not always on a session. The user is logged out, he ends up logging in on the browser and the mobile product owners would not have it. And you know what? They're right. That's a sub-optimal journey. That's not what customers expect. And that's actually the lens that brought us to look at very fiber credentials as a potential solution. And what is the idea? We said okay, the countries all own the customer. They know who they are, they have verified kyc, they know the entitlements, what they should or shouldn't do. Why don't we issue all that into a wallet, use it as an identity wallet and use that as a universal mobile first citizen way of authenticating our customers.
And that's how we went about doing it. So basically clients relying parties on the left side and it doesn't matter if the web or mobile they do open ID connect was very important for us to do open Id connect core and not, you know, destabilize their journey and have them learn totally new standards. So there was also a design requirement we discussed with Ping, they have to know nothing about it. So they're doing open Id connect and say I wanna know profile, email, phone, et cetera. And I'm asking for a specific scope is an entitlement. So all that reaches our ping federated we put up two years ago and in case and then, and then Peder comes to decision point basically now we have wallets in the game. So how would you like to proceed if you have a wallet? We actually don't, not gonna ask the the user, but if there's a wallet on the device, we're gonna do that as a seamless transition.
It's gonna go to the wallet. That's great. If it's a cross device flow, you have a wallet but it's web to mobile. For example, a QR code is gonna pop up and continue the flow there or maybe you didn't do it yet. I don't have a wallet do classic open Id connect. So that's what the user now faces, that's the service our is gonna serve them. And then in case they do have a wallet, now they have our bank ID use case specific credential there and they're gonna use it to make a presentation. So syop open, ID connect for vp and inside that credential we built a schema that says, okay, this is our customer and the customer identity here are the entitlements. They're both belonging to the same country and to the same user. So this contains all the classic openly deconnect claims of name, birthday, email, et cetera.
And this one contains entitlements. And yeah, that's great. You actually have an entitlement to use the requested scope. So the wallet is gonna continue in this case without even no question of consent cuz it's first party, it's, it's a banking gap you wanted to look into. If you don't have any satisfying entitlement, it's gonna say access denied. In some cases you might have more than one satisfying entitlement. And then we're gonna use selected disclosure. Maybe you are an accountant and you're serving multiple customers. So it's gonna say under what context are you acting now? And then basically the wallet's gonna be the place where those decisions are taken. And it's not gonna show this entire Jason story, but selective disclosure, we precut it and share what's relevant to the specific use case. So now the verifier does all this magic and our pinged then processes the presentation and the app, they didn't feel anything.
So they do open, ID connect like they did before. If the user has a wallet or transitions into wallets, they can use them. If they don't have a wallet, nothing breaks. They do open. Id connect whole federation like before and, and of course the countries maintain full control. They're the one issuing the user the credentials. They're the ones who know if maybe this customer closed the account, something in the status change, got a new entitlement, lost in entitlement, they have full control in this updates in real time with revocation and reissuance. So we're quite excited about that and having explored that journey where we of course discover new lenses, new outlooks, new opportunities that this could bring to banking. So right now when we want to onboard a new customer and remember Corona times for example, digital onboarding, remote onboarding, that's not a very easy journey.
We are afraid of fraud, we gotta do high level k yc. So we gotta, we gotta look at the documents that the user is sharing. We gotta do a video chat, a liveness check. A lot of risks in that realm. Well you guess what? Once they have European identity wallets, other identity wallets, we could swap that and just onboard them with the national IDs on the wallet, better for the customer and of course better for the bank as it provides higher levels of assurance. What about shopping? When you wanna shop and buy at whatever shops they need to know who you are. Let me click away there.
Yeah, I mean any, any merchant out there needs to know who's the customer that they're serving, where to deliver the product to, what is the email that I'm gonna communicate with you. So instead of providing the user with a very tiring form and have them fill that out, it's possible to take the validated I identity from a bank. So you know, anyone can open a Google account and enter whatever details, but those are details that the bank vouched for as part of K yc. So that opens the, the door for collaborations with such organizations that can benefit from the KYC as a service.
What about cross-border banking? I mean on, on the one point, maybe the user banks in one of our countries and then goes to a different country and he wants to buy a property, he wants to open a business, he wants to start bank there. They need to know that he's legitimate, that these are not money laundered funds. They need to know provenance of the funds. So this is a use case of cross banking that can be explored. You know, there are many chains and frameworks of trust that can rise, where you can share this information in a cryptographically verifiable way and support these new use cases and digital approvals. We've been looking very much at, at SBA in our case, how can open a deconnect CBA service? You need to sign a transaction, you need to give a digital approval. And because of our specific makeup and network, that has not been so simple. But hey, if we're gonna give them wallets and wallets have a private key in them, hey maybe we can discuss directly with the wallet now that we have this relationship and drive the transaction approval directly from the wallet.
So
To sum up, we discovered that this can solve use cases where federation has reached its ceiling and couldn't take us to the next phase. Opens the doors to a lot of other use cases that can happen. And just exchanging it, talking to some of the people here, brought three or five more of these fascinating use cases and doesn't break anything. This is like paramount for us. Don't force the customer to break in one day, don't force the applications to change. Give our banks still the full control over the customers and have everything, you know, introduce smoothly the new capabilities. Thank you very much. No,
Very thank you yarn. And we do have a booth here, booth 25. You wanna come and see a demo and even see some of the core tech that's being used at the bank. You're help. Welcome to come to see that.
Thank
You so much. We still have a few minutes and we also have some questions online. How did you address K Y C requirements related to customer onboarding with verifiable credentials?
Well, we actually didn't do customer onboarding yet. We rely on the existing K Y C and we simply use verifiable credentials to transform or transfer the existing K YC that we have into a verifiable credential. But digital onboarding using verifiable credentials, we're waiting for E U D I and identity wallets to emerge. And then we could say, okay, the governments trust this person, then you know what, we don't need the video session. Let's just verify that identity. So we're not there yet, but it's definitely on the roadmap. Perfect.
Tyler, you want to add anything to that?
Yeah, one of the things that we can do is do device trust. That's another big question around kyc. Is this device trustworthy? And so we have some great partners that provide connections through our DaVinci framework that can go and even validate the sim and authenticate the SIM of the phone as part of the transaction. So we're exploring with WiFi's and how to also do device trust alongside any kind of identity verification add-ons as part of the experience.
Perfect, thank you. There's one more question. Are the benefits for the responsibility for security of the wallet?
Sorry, could you repeat the benefits? Do they overcome the,
Are the benefits worth the responsibility of the wallet?
Well, the benefits are clear to us. We came to a point where we are blocked, right? We wanna roll out centrally build mobile apps to all our countries. We don't have a better solution. So it's, it's a clear make it or break it decision in this case, but we don't have, we will roll out a wallet, but that's not our ambition. We will look very closely at what's happening with the open wallet foundation, with the e UDI and following the tracks of governments. So we start with the wallet, the P supplies where we can control that we get the right security profile that everyone with compliance and security are happy with. But down the road we wanna replace it and go for the, yeah, government approved wallets, A R F approved wallets.
Perfect. And talking about wallets, do you enforce the customer to use any specific digital wallet or is it open for the customer to choose?
In the starting point in our solution, we forced the wallet. We have not identified yet enough maturity to say, yeah, it needs to go there. But speaking to the people leading this field here, there's, there's a view on how this is gonna emerge. That at the end the wallet is gonna be like the browser, right? You can use your browser with government services, banking services, and they don't main mandate one browser. So that is the product of community certification. And when this maturity will arrive, we could trust any wallet.
Perfect. Thank you so much. We have one minute left. So if there's any question in the audience here,
Questions speak up. When you see the European wallets are you think this wallet take away?
Well some of our countries are European where we bank, but they're not eu. So our, you know, the adoption in these countries is not just gonna be same step and same speed, right? And even as, even though the U countries might not move at the same speed, so we don't know. But the ambition is not to have a wallet. It's not that we said, oh, we're gonna have our amazing wallet and that's like a selling point. We do it to achieve, you know, the security and interoperability benefits. But down the road if, if emerges in the countries we operate a wallet that is certified that that provides these values, we'll want to pull to that wallet. Which is why credential portability is one of the requirements we are strongly discussing in this solution.
Perfect. Thank you so much Tara and Yaron. That brings us towards the end of this session. Next up we have, but first give around her plus two. This one.