All right. Good morning, everybody. Thank you all for being here. We appreciate you guys coming out on a Friday morning with what I'm sure has been a very long week. If some of you had the chance to catch the presentations for some of our colleagues yesterday, you had a look at what's going on with the Germany's wallet and also a bit of a preview of what's going on with the UD Hub and the plans for the ecosystem more broadly as we move towards production readiness towards the end of the year.
So while those talks yesterday focused on where we're trying to be in the months ahead, today we'd like to look at what's been going on in the ecosystem in these past six months that we've had an operational sandbox. And who we are. Maybe. There we go. Okay. So I'm Gabriel. I'm responsible for developer relations on the ecosystem team. With me today is Arjen. He's the integration engineer on the team. And along with those roles, we're both also jointly responsible for the technical documentation and resources available to participants in Germany's sandbox currently.
And what that adds up to at the end of the day is we are essentially the frontline workers for anybody currently testing in the ecosystem. If that includes some of you in the audience today, we apologize for any messages we haven't timely answered. But you'll see a few slides later how outnumbered the two of us are even at this early stage. So I guess before we can talk about what's happening in the sandbox, it's useful to go over what the sandbox actually is. Because it's not an approach that's being used by a lot of member states currently.
Beyond Germany, I believe France, Austria, and Moldova are the only other member states offering something resembling a sandbox environment at this time. And that, of course, leads us to a more basic introductory question of why have a sandbox to begin with and what we're hoping to accomplish. And the answer is something you may have heard from others in our team already. And that we're not building an application, we're not building a service, we're trying to build an ecosystem. Something that grows and survives with us in a more passive role at the end of the day rather than front and center.
And some of the pillars that we hope a sandbox will help us in building that ecosystem. First and foremost is by, at the earliest possible stages, empowering relying parties and EAA providers to onboard and get started. Because while some of these organizations will come in with a wealth of knowledge and experience working in digital identity, an equal number will come in as their first experience working in this space, will have a much steeper learning curve, and will require a different set of tools, resources, and assistance to get them up and running.
So for these early adopters or participants in the sandbox, they're getting set up for success on day one when we go into production. And for our part, we're learning the sort of resources and tools we need to provide to enable future participants to get up and running quickly and easily, no matter where they fall on that knowledge spectrum. And also by bringing all of these organizations together in a single location, we're opening up potential marketplace for service providers to operate.
And from the limited data set we have in the six months we've been operational so far, we can already see what a tremendous accelerant service providers can be in getting relying parties up and running quickly. So we want to build and develop an operational model that enables these service providers to work and thrive within the ecosystem in a mutually beneficial arrangement at the end of the day.
And again, by having all of these parties together, we're hoping to spur the formation of different sets of working groups where they can collaborate together, whether by industry, by use case, in whatever ultimate format is most useful for them to build up the ecosystem. Because at the end of the day, it will be these third parties, not us on behalf of the orchestrator operating the ecosystem, that puts a finished product that makes it useful and enticing for the general public to use.
And these three pillars together essentially form a continuous feedback loop for our part to learn and iterate on the experience, tools, and resources we provide. The ultimate goal being that every new relying party that onboards into the ecosystem has a simpler, quicker, easier experience than the party that came before them. So that being the idea of the sandbox, what it actually is at the end of the day is as near as can be to a testing environment aligned to what ultimately will be the production environment here in Germany.
I say as near as can be because we know it's a moving target right now with evolving regulations, amended implementing acts, and constantly changing feature sets. So it's a safe space where all of these participants can test their use cases, build their integrations, and do so with test data.
And again, a safe space without any real consequence to a mistake on our part or a shortcoming on their end. And at the end of the day, it's the test data that is the single most meaningful distinction between the sandbox and the live production environment. Because ultimately, the sandbox will continue to exist. It's not a temporary solution to get people to production. It will always be the first step and a requirement before they're able to move into live operations.
So in terms of how it operates on a day-to-day basis, it's really taking all of the different moving pieces in terms of wallet feature set, updated regulations, changing infrastructure on our end, and constant implementation on the relying party side. And using that to iterate and expand the tools and the resources that we make available.
Again, with the end goal being that we're all learning together and building the ecosystem that will function more or less autonomously in the future. And along with learning all the things we should be doing, it's equally important to learn the contours and limits of our role as the orchestrator. Because while we're here to facilitate participation in the ecosystem, we're not here to mandate or direct it in any matter. So we also don't have the ability at the end of the day, even if we would want to, to be hands-on with every particular relying party or EAA provider in the environment.
So we're doing everything to facilitate ultimately a self-service support model where people can collaborate together, focus in their respective industries or working groups, and ultimately be able to solve their own problems rather than being constantly relying on our intervention. The way that's done is by providing a shared communication channel. So that this is for every relying party and participant in the ecosystem currently, not just to speak with our team, but also with the entirety of everybody else currently testing.
The idea being that giving them industry-focused channels or doing matching between them and a provider or a service provider, they're able to build up a shared knowledge base that will persist and help the next cohort and the next dozen, hundred, however many, may ultimately turn out to be when we move towards production. I alluded to the scale a little bit earlier. I checked actually this morning, and these numbers are already out of date.
They're quite a bit higher already, but we have about 115 different organizations testing about 150 different use cases across every conceivable major sector. I think you probably include travel, transport, and logistics as well on that list.
And again, across those industries, every conceivable from the most simple to complex use cases, it's what's actively being worked on in the sandbox currently. So while that was the high-level vision of what we hope to accomplish with the sandbox, the day-to-day reality and challenges, I'll hand that over to Aryan. Cheers.
Hello, everybody. So as Gabriel mentioned, we've been operating a sandbox for six months now, so we thought it would be a good moment to take stock of the type of interactions that we're having with relying parties and now increasingly EAA providers in our sandbox and identify some that are maybe less effective or improductive and also look at a bit broader what our friction points are and how they result from our early setup, our tooling choices, and how we envision change in the future.
So to kind of start to paint a picture of the run-up to the launch of the sandbox, we made a few choices early on. As Gabriel said, we were already tendering for the EODI hub that our colleagues talked about yesterday as well. We were building the wallet for a while, and now what we really wanted was to get our piece in the sandbox as quick as possible, do it manually, and just get them on the road. And so it was important for us to create very low barriers for communication with us, but also with other participants.
And what we were hoping for was that this would enable people to give feedback in a way that was convenient for them and also cross-pollinate with other ecosystem participants. So that was our first move. We staggered the entry of participants so we wouldn't be overwhelmed by hundreds of RPs entering in one go and us simply not being able to respond to the amount of traffic coming in. And obviously we want to use this for the design of our EODI hub features that are coming up.
So now I want to run through a few different types of interactions that we have with relying parties that are ineffective. And the first one is an ask for help with too little context for us to actually provide that help. I think we see this in many different places, but this is also something that we experience now. We'll talk about what we learned from this later. The second one is the relationship between the relying party and the orchestrator. And this can take many different forms, as you can see on this slide, in the terms of questions that they ask us.
This is not a surprising outcome to us because our role as orchestrator is actually quite unique. And so through our interactions we actually set the boundaries of what we do and do not do. But still we see that relying parties may come in with an expectation that we are either consulting for them, can offer them a software product, or even that we're kind of running like a platform and so all the rules are already determined and there's no decision making to be done on their part. So an understandable issue, but something that we see in many different forms in our early sandbox.
Then we have the everything machine, also something that you're probably familiar with. People who want to start big and transform their business tomorrow. Or they see the wallet as an opportunity to implement a feature that actually the wallet is not really intended for. And this is actually quite difficult for Gabriel and me to deal with because once somebody made a plan, how will you convince them that they should change it? So this takes a bit of time. And then finally we have the AFK RP too. So we see them on board.
We know that they create certificates in our ecosystem and download the wallet app. But you won't hear them ask questions or make comments or really interact much with others.
So yeah, those are four different types of ineffective interactions we have today. So what can we learn from these different categories? In my opinion, these no-context requests for help actually tell us that our self-service model tooling and documentation is not good enough yet. For relying parties who do not have identity expertise necessarily to iterate independently, find errors and then correct them themselves. And if we want to continue scaling, this is something that we need to achieve.
Additionally, what we want at UDI Hub is that the tooling itself should build the context as we go so that we don't rely on the goodwill of the relying party to provide us with all the information we need to help them. So we just have to make it simple. And we are doing this now, so we're setting up a more traditional professionalized support team with levels of escalation where context is built up along the way.
For the relying party orchestrated relationship, all I can say about that is we need to keep repeating the vision of our ecosystem and what we're trying to achieve until it is just more well-known. For the everything machine, I think we have to accept that we don't have a lot of control here, but what we can do is develop design best practices and highlight uses of the wallet that might not be too appropriate so that people can self-correct early on. Some broader friction points we see in our early sandbox is the wide variety of RPs is really a challenge for us.
We need to create a learning trajectory that takes somebody from start to finish, but at the same time provide tooling for experts that is easy to use and is not too cumbersome for them and assumes their knowledge. The multi-channel bug reporting and communication that we entered our early sandbox with, in my opinion, was a mistake. We don't see necessarily that it's a real requirement for RPs to be able to communicate with us in the ways that they want.
We see that they are actually very keen to provide feedback and talk, so we could have saved ourselves a bunch of overhead if we just stuck to one channel here. Then we've been asking ourselves how we measure success. How do we know that by the end of 2026, we have as many relying parties and EA providers ready to go into production as we can?
Right now, we can see who enters the sandbox, how many, and whether they register certificates, but we can't really see whether they actually have a successful implementation in the end. We rely on them self-reporting their success to us, which creates low-fidelity data on actually who is ready to go. This is something we're still thinking about, how we want to approach this.
Lastly, we really have to start distinguishing more between community building and support. Gabriel and I do it at the same time in a mixed environment right now, and we see that this is not working necessarily. A lot of relying parties will always go through us before talking to anybody else, so a mixed model doesn't work too well for us. I want to wrap up with a few quick lessons learned on the posture that we think makes relying parties successful and the things that we want to change. A successful relying party has the right person in the right role.
A little bit of expertise goes a long way, and we see in our sandbox that people with prior identity experience are much faster at integrating than others. This is something expected. Successful RPs are small teams with focused business outcomes that they want to achieve in the sandbox, and then test. This is our step one, this is our step two, and they start iterating from there. Our successful relying parties also communicate in public channels. We see some who only ask questions in private messages because they think, well, maybe this is a dumb question.
The people who communicate in public move the fastest. And then to wrap up what we learned, we need to be creating structured conversations. Freeform conversations between us and relying parties and EAA providers will happen, but the structured conversation is what we need to supply. We need to keep betting on self-service first. It's the only way that we can scale. And we need to be able to remove ourselves from the development cycle of our ecosystem partners. And finally, we can't wait for the EODI Hub. We think it will make life easier for both our partners and for us.
So thank you for your interest.
