A Practical Guide for EUDI-Wallet Use Case Implementation for Organisations

Awesome. So we heard a lot about digital wallets, the European Digital Identity wallet, and I wonder like what our experience so far, so let's get to know each other a bit better. I would like to ask you to raise your hand if you're familiar with the scope and the functional scope and the Yeah, the capabilities of the European digital identity wallet.

Yeah, I would say that's half of the room. That's good. And who has already practical experience with implementing use cases and testing use cases with the standards and the architecture reference framework? Hands up.

Yeah, that's nice. I would say that it's maybe 20 hands or around 30% of the room. And here the divide starts, right? We talk about a topic which we deem important, which we yeah, discuss a lot, but we lack the practical implementation experience to really have, yeah, a solid foundation and an informed decision to say, okay, are we, should we go the the, the left direction, the right direction? How we should approach that, right? So that's crucial, really practical implementation experience to really get the user experience going, to better understand the process flows and so on.

So we can discuss that longer. Yes, but as long as we don't have this experience and practical implementation, we want to really get forward. So that's what I want to talk about today. How do we get there? How do we get more practical implementation experience? And I'm getting my pointer here. And I think the best way to approach that is a pilot, right? We still all know that there's some, yeah, open topics which we need to approach from a legislative point of view, but also from a technical point of view.

So having a pilot gives you the opportunity to prepare for the regulatory requirements of the new AIDAS regulation. It enables you the testing and implementation of the use cases to better understand the processes, the user acceptance aspects of it, which are really crucial, which we don't talk enough about. And also do a validation of a technical, a technical integration. And you can get strategic insights right into what is going on on, yeah. On the EU level with the large scale pilots and so on.

And to do also risk mitigation if your organization is yeah, mandated to support the wallet if you're bank, if you're telco or an insurance or any other organization which needs to do know your customer process and identification or a strong customer authentication. And obviously this is highly strategic relevant topic. So a lot of organizations have that on a C level, on a strategic topic and they say, yeah, this is, I wanna be a first mover here, I wanna be an innovator and I use this as a strategic advances going forward. And then a pilot, obviously a way to go to build the experience.

So usually how is that as approached is that you start with the initial assessment and knowledge building. So you, you gather your team, you decide who in your organization is responsible for the topic, who takes over what and gather the knowledge, right? It takes obviously the regulation itself, the architecture reference framework and all the resources you can gather to, to have a basic understanding of a topic. And you then get into, yeah, but the project scope, you would define a budget for it as well as yeah, the general structure of it.

And you also speak out maybe when you go to vendors or to, to experts in the field, maybe external consultancy, to get a first feedback. Once you do that, you can engage with a stakeholder engagement and a requirement analysis. So you speak to your internal IT to the compliance department and the customer success department, whoever you should be involved in making as a decision. Because all of these compartment usually have their own set of requirements, which they get together to form a holistic set of requirements for a use case.

And that's obviously also then the crucial decision, what kind of use case you wanna go for. Obviously the decision for some is easy when they're mandated to do as a KYC, for example, with the pit, the personal identification data. But there's so much opportunity when it comes to about credentials in general.

So that's, yeah, requires an, yeah, thorough investigation and analysis and evaluation, which I would talk about in a second deeper. And then you can also speak about who you're gonna partner with. Usually you partner with a, with a, some software render or also an system integrator, right? Because most of the organizations won't do everything in-house themself they partner with. And that that's also something you, you wanna, yeah, take a look into what kind of partners do you need and what kind of partner do you choose?

And then you can move on to strategic planning and the roadmap where you can clearly define what's the project scope, when does it start, what kind of milestones you wanna reach and when does it end? What do you expect to do in this kind of mi different phases of the projects. And you also clearly define the use cases by then, what do you expect out of the use cases? And also how it aligns with the broader strategy of your organization, right? And then you can engage in a wallet pilot if you define all of that.

And then the wallet pilot also has a roadmap I'm talking about in a later stage H And when, when we talk about the functional availability of the wallet, we're always kind of dependent on what is going on in the ecosystem. So we can take a look on what we heard yesterday already, a bit about the German European identity wallet challenge. And you can be part of this challenge, which means that there will be wallets available, you just need the right kind of software to interact with these wallets. And then you can also implement the same use cases.

So what is bland is in the next, in the next month, we we're currently implementing the id, the German id. So you can do an I identification with the German pit. You can also do credentialing use cases, so called electronic attribute adaptations or might also be non-qualified or qualified. And then towards the end of the year, we can also do strong customer authentication cases, right?

That's the, that's the multifactor login, which, you know, when you log into your bank account, the second factor, right, that will be supported in the future with the wallet or any kind of approval, for example, for approving payment transaction, right? So there's a lot of room and opportunity for banks and institutions to, to go into that and take a look at what is possible. And that's the roadmap you can join. But obviously you, you wanna first also know what kind of roles there are in the ecosystem, right? You need to know what roles you depend on, what your role you will take.

And you might only be one of these kind of roles, you might be multiple of these roles. So classical issuer holder, verifier, yeah, constellation. And this is also really important to understand where are you and who you depend on. And then when you take, when you know that you can deeper dive into the use case itself. And a lot of people ask me, what do you think is the best use case? And by the way, I'm also sharing the slides in the end, so you know, I'm happy to share that in the end.

And the use case itself is interesting and so far that we have this huge opportunity of a lot of different use cases when we talk about credentialing in general. And there is no general idea of what's the best use case because it highly depends on your organization. What do you need as an organization? And I came up with a set of characteristics we can use to evaluate these kind of use cases for your organization. For example, the market and ecosystem. So for example, if you wanna do an employee pass, right? What is the current market of employee passes?

Is that something you wanna compete with? Are there existing solutions which already fit your requirements? So that's something you wanna take into consideration. Also how easy it is to create an ecosystem around it. Is there already parties who are interested being acting as an issuer for that or as a, as a relying party? And so that's something you want to take into consideration. Also the use cases and the stakeholders. So for example, if you want to act as a relying party, are there actually issuers who are interested into issuing the credential? You want to verify, right?

So all these kind of dependencies you can evaluate. And also on a feature set and feature requirement topic, you also need to ask yourself, are the feature requirements I do have for my use case, actually supported in the architecture reference framework?

If not, that's gonna be difficult. And also super important, the use itself, frequency of usage for example, very important. Are we talking about 100 users per per month or are we talking about millions of users per month, right? Really important distinction. And also with disruption potential, right? Is this use case helping you to maybe target a new market which you were not able to tap into before, right? And that's also some, like a lot of aspects.

So what I did, I described that in more detail and I created a list where I came, where I set it out and a sheet and you can yeah, say one or five to saying in terms of how, how you think, how value that value is there for you. And then you can create a scoring and easily compare different use cases for yourself. I'm happy to share that with you, with you the end, provide the information for that. So now you've decided on your use case, you know your role. Now let's take a look if it's actually a possible, so what you wanna first do is identify the stakeholders, right?

Who's the issuer, who's the holder, who's the verifier? And you want to make sure that you understand the benefits for all of these roles. You understand also the barriers to entry for all of these roles. And you do expectation management, what do they expect and what are potential challenges? And you wanna start basically with the demand for the verifier. If there's no demand for the verifier, then what's the point of issuing your credential in the first place?

So they, they need to be able also to, to verify that they need to be able to, yeah, have to, to actually be implement that, right? So there might be legal hurdles when it comes to liability and so on. So that might be a problem. So then you need to have interest of the issuer. They might be compelled to, or like they might be mandated to issue it, which would be amazing for you, right? As a relying party. But they might search for a financial interest, right? They might wanna be paid for a credential, which we currently don't have as a function in the IDOs.

So, so you need to, to come up with other solutions of how this might work in a workaround, right? And we also have the, the user focused topics where you access the, the KPIs for your use case in general, what you want to have, what is the benefit, the perceived added value for the user and so on. So these are the topics you want to evaluate before you actually start implementing the pilot. That's something you ask, you need to ask yourself before. And then when you did all of that, you wanna choose a wallet, right? I highly recommend taking the one from the large scale pilots.

They do active testing, interoperability testing, and there are a lot of them. We have EWC alone, four wallets, which are compatible. We can use our lii wallet, which is available in certain languages, but I would recommend not only choosing one, one wallet, but in best case multiple wallets and then you need some software or be able to interact with the wallet, right? You need to be able to issue a credential to a wallet to request it and so on.

And for that, that's not easy in terms of how to do it because highly technical and if you're an organization, a bank, that's not really a topic you wanna deal with. So if you're an organization and you want to do implementing use cases, they're basically free options of how you can approach that. You either, you go for an in-house development, so you develop all the all of it yourself. But that thing is, that takes quite a lot of money, quite a lot of resources.

We, we have a team of around 12 developers who do that for four years already and took us around 14 months and we're not even finished yet. So, so that's quite, quite an investment. The thing is, having the connector alone is super difficult or basically impossible to achieve a competitive advantage because you're dependent on the wallets. You have inter like standards which you, which you basically implement.

And yeah, how do you achieve a competitive advantage with the connector alone if you don't control the wallets, right? So it's a standard software so you can, I also use open source that's highly flexible. It's a very cost, cost saving or low cost, yeah, option for the initial experience.

However, you might get limited guiding, guiding in the experience in terms of the support. Also, you might not get service level agreements and you also don't know, you're not sure of how long this avail this project will be maintained, right? So as an organization you want to have investment security and make sure that what you're trying would you building experience on what you're integrate in your own, it is available in three, four or five years and maintained for that time. And also with service level agreements.

And that's why most of the organizations, especially big regulated entities go for professional vendor, right? So they obviously they're, they have to have a license cost here, but you have a long-term commitment from them to ensure state architecture, reference framework compliance or regulatory compliance or technical level. And also in terms of like a guidance service level agreements. And they also have partnership with professional IT integrators.

So that's the reason why, yeah, a lot of go for these kind of AI vendors, we are one of them, but look at the large scale pilots there, we're not the only ones. So there are certainly some options to choose from. And when you, when you take a look at this, what we call a European identity wallet connector, some call it also an adapter or a middle, middle layer middleware software, you wanna evaluate a decree of compatibility to the architecture reference framework. So not to build with all standards or with something which is not compatible with a lot of wallets.

You wanna make sure that it supports the required features. Might, you might wanna only issue something then you don't need, then you don't need verification, but you still need revocation, right? So that's also something you wanna take a a look into. You also wanna take a look onto hosting, right? You might wanna choose only cloud or only on premise. You also wanna take a look into the compatibility with existing IT infrastructure.

If you, for example, as a qualified trust service provider, want to use it on premise and want to connect your own key store that needs to be compatible with your key store and also with your databases and so on. So that's important aspect. Also the stability of the endpoints of the APIs and so on, as well as the whole trust management around it.

And also multi-tenancy capabilities, which means that you have one house with a lot of tenants speaking one application in your environment and you have a logical separation of the, for example, members of your association or departments of your organization. And as well as the general execution of the user experience. The user flows super important overlooked by a lot of par peers in the industry or like in general in the industry I would say. So that's also important.

And when you start a pilot, then you usually have a kickoff with the partners and you then go for the IAPI integrations by then you define the use case already and so on. And you do internal testing to make sure that it works. As expected. You then do the user journeys with the blueprint, with a happy path and an unhappy path and also start then if you finish that with the implementation of the pilot itself with, with might be external users, but certainly with the limited set, this might be beta testers and so on, but certainly not, don't just throw it out to like productive crowd.

But take that as a steps, maybe 201st or like thousand to build the initial experience. Then you continues monitoring that, you gather the experience and you do then yeah, a final assessment where you say, okay, continuous improvement, continuous monitoring. And at some point you finish the pilot where you say, okay, you might wanna transition it to a productive use case if that's possible already. Or you might need to go into a second iteration if there's still topics you need to address. So that's how you generally approach a pilot.

And I'm happy to share not only the slide deck but also yeah, the, the use case evaluation sheet, which I mentioned. So that's, I'm happy to share. And also if you are interested to talk about that in more detail also our pilot program we offer, I'm happy to share that with you.

And yeah, I'm looking forward to, to continue the conversation. Thank you. Thank you. Thanks very much. Excellent stuff.

Just a, a quick question as we're a bit time time, but just, just one, it feels like there's maybe tens of thousands or hundreds of thousands of organizations in Europe that are gonna have to do this. So how much, how many can you do a day do you think? At list For us, I, It's gonna be massively busy, isn't it? So at some point we will have this kind of peak of demand where all the organizations realize, oh damn, we have to do something.

And at least we're only software provider, so we partner with the professional system integrators, which then do the integration of our software at the client inter IT infrastructure. So we, we, we try to not be the bottleneck, but still we will see how much we can be able to scale.

Yeah, it feels like people are gonna have to get in the queue pretty quick. I, I think 'cause especially the regulated industries that have to comply. Yes. It's just a matter of time. Yeah. Yeah.

Okay, we'll give him a ring when you're ready, Adrian. Thanks very much again. Thank you.