So hello everyone, my name is Christian. I work for the German UDI Wallet Project. When I say that, it's a project that delivers the wallet, yes, but it's also responsible for building the whole ecosystem. So all infrastructure, making sure we have use cases, it's a lot more than the wallet. I've also been heavily involved in the standardization of all of the surrounding protocols, so mainly OpenID Foundation, IETF, and I want to give you a bit of a real-world perspective on conformance tests and why they're important.
And I try to roughly give you an overview of the complexity we are dealing with right now when we're trying to implement stuff. So if we're trying to implement UDI, we have a rather complex landscapes from the regulatory perspective with tons of implementing regulation. There's roughly 50 implementing acts that are surrounding this whole identity and trust services space. And then you have a lot of nested dependencies, and technically this is not fully correct, but it gives you a decent idea on the kind of complexity we're dealing with right now.
It's really hard to go from implementing act at C specification, which is a profile of hype, then you have hype, which is a profile of OpenID for VC IVP, and then you go to the OAuth layers. It's really complex to implement everything correctly. And we've seen that, well, having some form of test for those implementations is extremely helpful. And we've seen that also during the development phase of the standards, right? So during development of standards, we had a lot of interop events.
So in the picture, you can, for example, see last year at Bundesdruckerei here in Berlin as well, with a nice interop event for, I believe it was DCAPI and hype, NVP. And that was extremely helpful for the development of standards. But I would also say that the early conformance tests were actually really helpful because it kind of created a baseline.
Like, it didn't start at zero when doing interop tests. You already had a rough idea on, okay, base stuff is here. And we are right now in a phase where standards are final.
Last year, we've gone final in OpenID for VCI with VP, VCI, and hype. So like three standards in final, 1.0. We are now in a phase where everyone is trying to implement. And I've shown you before, this is rather complex to implement properly. So it's really important that we have something that helps us make sure implementations are correct. And right now, we are still in this phase of like the first, like fast adopters are implementing. That usually means wallets or service providers. And that is where it becomes interesting and where we are seeing a lot of pain right now.
We have something called the German UDI wallet sandbox running right now. This is something right now we are in a closed sandbox phase where we are like step-by-step inviting interested parties into the sandbox because we want to have as many use cases live as possible when we go live next year. And we have a session that on Friday, if you're interested on lessons learned, from the beginning, we had a concept of having technical writers and people helping with integration, et cetera. And it's still super painful.
Like our lessons learned is we need to have really good documentation to get verifiers or parties on board. And automated testing is super, super valuable because if you don't have that and you're trying to build an ecosystem, like everyone will like send you messages or emails or like this doesn't work, that doesn't work. And like 90% of the time, it's like some simple configuration misstep. And it is extremely valuable if you have tooling to catch that. And that is, I think, where Joseph comes in. Great.
Thank you, Christian. So, yeah, so my name's Joseph Heenan. I'm the standards specialist and head of certification at OpenID Foundation. And I'm also the CTO at Authleet. But I'm here with OpenID Foundation today.
So, I lead the team at OpenID Foundation that develops certification tests for all of our protocols. As Christian said, just implementing the standards isn't enough to actually get that interoperability. You really have to test it. These are complex things. Automated tests are really the way you make sure these things are right. And we've been doing this for a long time across various different of the OpenID Foundation protocols. We try and test them all. And these tests have actually been mandated in some of the ecosystems for participants to use.
So, in many of the open banking ecosystems, the regulator says you have to run the OpenID conformance test once a year and submit a certification. And that really helps level up the ecosystems and make sure that the third parties that are trying to connect in actually have a chance of doing it in an interoperable way rather than tweaking things for each wallet or each bank, which is just a nightmare. And it really makes sure that people have implemented the standards correctly.
So, you know, if you're a wallet and you have people implemented to you and you want to make some updates, you really want to know that they have actually implemented the standards correctly. Otherwise, you might tweak something innocuous and everything else breaks.
So, this really gives us a baseline of interoperability that really helps us scale these ecosystems. And there's quite a few ecosystems already using our tests.
So, the UK was the first to go live in open data and open finance. Then we've had Australia, Brazil, a couple more that are in pre-launch. We've got Canada and the US that are hopefully going to be coming online with the tests and then obviously with the digital identity ecosystems. We've been working closely with the EU and there are other ecosystems that might come in online in the future that might want to use our tests.
So, the tests we build are actually open source and free. We build them on GitLab in the open. We try and build them before the tests actually go to final because they really help prove out the specifications. We catch a lot of ambiguities when we're writing the tests and make things clear. And then as people test, we find they've got different interpretations. This all helps really make the specifications a lot easier for people to read and implement the correct thing the first time.
And when we write the tests, it's like every step in the test, we try and map it back to a specification course so people can see why we're doing a particular thing. And it's all very transparent and debugged. And as I say, there's thousands of people have actually run tests on these systems.
So, we actually know they work well. And we develop them very closely with the working group.
So, we go through beta processes, get the working group contributors to actually test the tests and prove that we have actually interpreted the specifications in the same way that the people writing them intended them to be interpreted. And we also take part in interop events. I'm actually going to an interop event in France next week for ISO, where they're going to be interoping on MDLs and vehicle registration certificates and all kinds of other things in combination with the OpenID protocols. And we obviously, we maintain these tests. We keep them up to date.
If people find new and innovative ways to interpret the specifications that aren't correct, we can add extra checks in to kind of try and bring people back in line. And OpenID is a non-profit.
So, we want people to actually be adopting our specs and be adopting them correctly and using them and these ecosystems to scale. That's really our mission. You can actually submit a formal certification. A self-certification. If you pass all the tests, you can pay a certification fee, then you get listed on our website as certified. That's particularly if you're a vendor, that can give you some good marketing kudos. People buying your product may well look for that kind of mark to know that you're actually compliant with the standard, rather than just saying you're compliant with the standard.
But the fees are fairly low. So, you can actually submit a certification. But the fees are fairly low and fairly reasonable for members for a wallet certification. I think it's like $700, which compared to some of the other certifications you might be needing for a wallet is pretty reasonable. I'm just going to give, hopefully give a very quick demo of how the conformance suite works, just because people often say to me, but you don't actually have testing for Android wallets, right?
No, no. We have testing for Android wallets. We have testing for everything.
So, this is testing presentations for a wallet. You can see the conformance suite on the left. That's the configuration form.
So, there's various options you have to pick. You have to fill in some fields to give me a dockle query that actually returns a credential. Give me a key I need to use to sign the request. And then you just create a test plan. This gives you a set of tests to run. There's three in this case. You run a test. This is going to give me a QR code now, because it's doing a cross-device flow. I scan the QR code in the wallet. It does stuff. I authorize it to release the credential to the conformance suite. And then on the left-hand side, we'll see the tests jump to past.
And that's literally how fast you can test these wallets. Obviously, a few setup steps to get the keys right and things, and then you go on and do the next test. But this is really quite a simple process, and it's all automated. And as I say, there's lots of detail here if anything goes wrong.
So, we have these tests for both the issuance and the presentation protocols and type, or in particular, it's hype we're focusing on at the moment. That's the interoperability profile. These tests are to promote interoperability. These tests are in final testing at the moment. We think they're basically feature complete. We've had a bunch of wallets test them with tweaked things based on their feedback and verifiers and issuers. Test support, testing everything. You can test an issuer. You can test a wallet and how it does issuance. You can test a wallet, how it does presentation.
You can test a verifier, how it does request presentation. It's all covered. And we've been working with the European Commission to ensure that the tests can be used as part of EUDI wallet certifications, which are obviously a much bigger and much more complex thing. And this is where the conformance program starts to really scale and we start to need partners involved because the EU requires conformance assessment bodies registered in each jurisdiction and so on, which is not something a standards body, a nonprofit standards body really has the scale to do.
And just one heads up is that from that video I showed, we actually have some user experience improvements coming soon. So don't be scared if you go to the test something in a month and it looks completely different. You're still in the right place. We just changed the UI. And with that, I will pass over to Mark, who's going to talk about how we actually scale this stuff.
Thank you, Joseph. So we've been running a program for a number of months now that was triggered by a realization and actually it was coming in from kind of questions from ecosystems in multiple environments that led us to realize we had a number of scaling challenges to sort out.
What we've had to date, as Joseph was saying, is the self-certification program on the left-hand side of this slide, where we provide a service, you pay as you go as an implementer, and there's fairly modest fees for doing that self-certification and getting your brand presented as a certified and tested implementation. And that goes up on the website. There's the link on that page if you want to find out more about certification there. We also have been doing arrangements with specific strategic ecosystems, particularly where there's a large number of parties being tested.
There's some volume-related discounts associated with that and tailored options to meet specific local needs. And that's the first hint that we need to scale. This is not a readily scalable option for us and is also not really optimized for ecosystem use. The key thing here is that the self-certification program was originally invented for testing software implementations, not testing productions. Production is an interesting word, but services that are delivering large internet kind of services into a population scale.
So amongst others, we need to be able to provide for specialist third parties to run testing on behalf of implementers. Some implementers do not have the ready skills to run the testing themselves and understand the output. They may be using a third-party software or services provider to deliver their platform. They may wish to have an independent testing capability at their disposal. And in some ecosystems there is the additional challenge of being able to be certified formally to a set of regulatory requirements.
The European Commission and European Union have been talking with us about this due to the scale of the EUDI project, the multiple countries, the multiple wallets, the many, many, many relying parties slash verifiers, and of course 27 plus plus plus issuers in that environment. There's also the need when you're doing that certification in the European context to not create a monopolistic situation. So there needs to be many, many conformity assessment bodies as well. So how many of these other things can I cover in time?
So yeah, there's a need to combine testing and multiple diverse requirements into a turnkey service in those contexts. So it could be that you need OIDF specs, FIDO specs, ISO specs, and a bunch of other additional ecosystem rules perhaps to do with how you process data, how you deal with incidents, you know, all of the kind of more audit-ish requirements that go into delivering a regulatory compliant certification. I think I've covered that.
And we, yeah, the final point there is that there are calls from some sectors to be able to do some sort of production assessments. And again, for similar reasons Joseph was talking about, the OpenID Foundation is reluctant to be processing production data. We're really not set up to be able to handle that in any sort of sensible fashion. So now what we're doing is we're building a third option where we enable third parties to come in. It's called the Independent Conformance Testing Program. What we're going to be doing is approving test service providers for specific sets of specifications.
The ecosystems can integrate our testing tools into their other requirements to create that certification kind of wider program. The test services providers would be paying OIDF on a kind of per implementation basis. So if you're a testing company and you test five implementations of FAPI, then you pay us five modest fees. And I'll come to the fee structure in a minute. There's more options going to be provided here to allow or not the publication of results.
And what we have discovered is that while software companies wish to make it very public that their implementation is conformant to a specification, ecosystem members that are doing it for compliance reasons don't feel that that's terribly important to them. Yeah, and there's going to be options about integration. Two minutes.
Thank you, Gail. I better hurry up. From a contract structure, OIDF is providing some capabilities here. We have the auditing of, yeah, we provide the rules essentially, which is the stuff on the left there. We are engaging with an authorized auditor. They in turn engage in contract with an approved testing service provider to check that they meet our requirements. And in turn, they can then engage with an implementer to check their implementation that has been done correctly and use an OIDF brand to support that assertion.
From a sustainability perspective, you know, following on from Joseph's deck, money does change hands. The testing service provider pays their auditor like you do any other auditor. And that's going to be a matter for a competitive environment. The approved testing service provider then charges its customers whatever it chooses to charge for testing their implementation. And a small fee is then passed back to the OIDF to enable ongoing sustainability of the program. And we're collaborating with a bunch of providers here.
There are candidate test service providers, candidate auditors, and ecosystems. And there's a timeline we're working to, but it's kind of dependent upon how the collaborators we're working with move forward. Pricing wise, we're breaking the fees into bundles focused on the needs of implementers. And that'll do. If you wish to know more, please reach out to the OpenID Foundation staff. And if you are interested in becoming a testing service provider, we'd be very, very happy to hear from you. We will be expanding our reach in that regard before long.
Oh, last thing, looking at Dima, he always reminds me to say this. We're not replacing anything that we already provide. So anybody who is an existing user of the conformance and self-certification services needs not worry. Thank you very much.
