Cloud Signature Consortium and Wallet-based Signing

Thank you, everyone. First of all, I was supposed to be joined on the stage by Sven, who is the Chair of CSE Technical Committee, but due to very last personal commitment, he wasn't able to come to Berlin.

So, Cloud Signature Consortium, who we are? Let me give you a brief introduction about this association, who was founded 10 years ago.

So, this year we are celebrating our 10th anniversary, and I think we did a lot in the past period. Now, we are covering literally all geographical regions, our members counting more than 80 from different backgrounds, like technology providers, public institutions, academia. They join us in our mission and vision to deliver open source standards in support of digital signatures. We have been referenced as CSE API within the Implementing Act related to wallet functionalities.

So, every relying party applications that would like to interact with the EUDI wallet to generate signature should implement the CSE API specifications. We also hold an interoperability test event this year in March that was actually the first of this kind, trying to understand how our specifications are landing in real-life implementations and where we can improve or what else we can do.

So, why CSE matters? What was the situation before CSE specifications? The cloud-based digital signatures were not new, so they started different implementations back in 2008, but every implementation had a proprietary approach.

So, in the case, a signing application would like to change the provider for the digital certificate, that would have required a different implementation, again, starting over and over. So, we wanted to fix this problem and to bring a specification that would allow remote signing applications to be interoperable with any digital certificate provider, just plug and play.

Then, we know that wallets now require a signing protocol and the EUDI wallets should support natively qualified electronic signature, and those qualified electronic signatures should be free of charge for non-professional use. That is another big question for the member states, how they can solve this problem or how much that will cost. We have heard the presentation of Hank before saying, what is the business model? This part is one of the tiny pieces of the business model that needs to be sorted out by member states. Last but not least, signatures are crossing borders, the API node.

So, as the qualified signatures issued in one country should be, must be recognized in other countries. CSC, Closing Network Consortium, provide this interoperability layer.

So, we developed three specifications besides the CSC API that now is version 2.2. We added data model and data model bindings. You need to understand all these three pieces, how they work together, and what are their roles.

So, we have the CSC API. That is the protocol. The version now is 2.2. We will release soon the version 2.3. And what is doing this protocol?

So, first of all, it's standardizing the interface between the signing application and the trust service providers. Then, it's helping to manage the credential life cycle because now you can not only use the credential, but you can create it and delete it dynamically. And last but not least, it offers backward compatibility because the option, the selection of the CSC API specification must be business driven.

So, every provider must choose what version of the CSC API is suitable for its business. So, not necessarily, perhaps they are not interested in generating signatures with a wallet.

So, they may have another business model and they will use a version that is version 1 or version 2.0. Then, we have the vocabulary data model version 1.0 that is establishing the common language for signing requests and qualifier. It is jurisdiction neutral.

So, it is working for EU, for South Africa, and every geographical region or jurisdictions can configure its own. And it's already reused in wallet protocols beyond the API. And last but not least, the data model bindings. That is actually the wallet bridge connecting the CSC to the UDI wallet via OpenID for VP, defining wallet request and approval flows, and what is important, ensure that the user, before signing, can consent and can see what actually is requested to sign. How the wallet-based signing works?

We have the request that can come from an application, from an external application, or from the wallet. So, the app or the wallet-identified document that needs to be signed, then the user must prove his identity. That can be done through the wallet or through an external identity provider.

Then, must select the credential that can be used to generate a signature. Now, this credential can be either a long-lasting credential or can be issued on the fly. This is one major improvement.

Then, the user consents, the user sees and approves what is signing, and that's it. The signature is created, the document is signed, and can be stored or can be forwarded.

So, what makes this difference? So, first of all, that wallet can be both a requesting application and also the driver of the signing flow.

So, the user can initiate by its own the signing, the signing action from the wallet or can be requested from an external relying party to generate a signature. It supports the short-lived certificate, so there is no need to pre-register to have a pre-issued certificate, and that is something that can really help member states to dimension as they go the usage and the generation of digital certificates for free of charge. Because I've heard many questions from the member states, okay, or many approaches thinking that, okay, the wallet must support free qualified signatures.

So, we have to issue by default for entire population long-lived certificates, which means a certain dimension of the infrastructure for country with 20 million citizens. So, imagine to issue 20 million by default certificates while you don't know how much they will use those certificates to sign. Then I try to explain them, look, not everybody will sign documents. Like retired persons, they may not need to send a tax declaration every year.

For sure, they don't need to do that. So, they won't need to sign a document. While active persons, yes, they may need to submit different declarations.

So, you don't have to overcharge your infrastructure and to generate by default 20 million certificates while you will have, for instance, only 1 million signing over five next year. So, you can issue as they go instant certificates and that will be manageable in terms of cost, sustainability, and infrastructure. And last but not least, what is different? We have the same flow that works no matter what is the trust service provider behind the wallet.

So, member states or wallet providers can be flexible in choosing the providers that are integrated with them to generate the signatures. What our interoperability event showed in March in Bucharest.

So, first of all, we had 18 teams. We wanted to understand how exactly it works when we have different wallet providers, trust service providers, issuers of certificates, signing applications coming together. They declared that, yes, they have implemented the CAC API version 2.2. Let's see together and see and test how that works like you didn't integrate it before or without any test of interoperability before.

So, from these 18 teams, we had 13 actively testing, a number of 44 tests, specific tests to signing with the wallet and with 82 percent success rate. So, this was really encouraging because we have seen the cross-vendor signing with independent implementations of the CAC API working, talking together, and functioning. We also had not only EU representatives, representations from the companies, but for instance, we had Adobe that came with Adobe Sign and worked and proved that actually this integration and this implementation is okay.

But we also identified some ages like providers that have these optional parameters to be handled across different implementations that showed a kind of differences in interpreting this. Also, the certificate policy interpretation is different by provider and the transaction data rendering is dependent on the wallet provider. All these findings are tracked on GitHub and we also have the conformance testing continuing online among those providers that join us.

So, we have CAC API that is one API. On the left side, we have applications that can integrate that.

So, we have the wallets, we have e-signing platforms, we have enterprise proprietary enterprise application that needs to generate signatures or governmental portals that require citizens to submit declaration. On the right side, we have the trust services issuing certificates that can be qualified trust service providers or not qualified trust service providers. We have certification authority, HSM infrastructure, remote QSCDs implementation.

So, you build once using the CAC API and you can connect no matter how many applications with trust service provider. But CAC goes beyond personal signatures. The same implementation and API can be used to generate electronic sealing.

So, you can use that for automatic sealing of invoices or of contracts and reports because we've heard many implementers are using a personal digital certificate to generate automatic electronic signatures of the invoices which is not okay because the owner of the digital certificate not only should technically sign but must see the content and agree. And in such implementation, the user, the owner of the certificate does not have any visibility and cannot consent of the content that is signing.

So, for that approach, electronic sealing is the right for those use cases. Also, the electronic seals prove the origin of the document and integrity on behalf of the organizations. And you have also different supported qualifiers for electronic seals compared to electronic signing. We know that the EU business wallet is coming.

So, through the EU business wallet, organizations can generate electronic seals. They will need to generate electronic seals. We will have for sure a dual wallet model with the personal wallet interacting with the business wallet where documents can be combined, both signing and sealed. At the end, we will have different signing approval models that will be possible implementing CSCA API. What's next?

You know, probably have heard that the European Commission is preparing now the functional conformance assessment framework where different standard organizations contribute to build this with specifications all related to their own standards that are developing. And CSCA will contribute with test cases in order to align their conformance work with the Commission's framework.

So, besides contributing test cases for the wallet signing conformance, we have also ongoing collaboration with ETSI, with OpenID Foundation. Our conformity checker for the time being is the version one, but will be updated soon to support version 2.2.

And also, we are planning to update by phase the API in order to support the technological evolution of the wallet. Looking ahead, just a brief summary.

So, first of all, we are working now to align the CSCA conformance with the Commission framework to update the conformity checker, continue the regular interoperability testing event. So, we will organize soon another event to support e-sealing implementation in the business wallet. And for that, we will run some pilots in WeBuild where different parties are implementing the signing and sealing in different use cases, expanding CSC standards to new regions and jurisdictions. And last but not least, ensure the market readiness ahead of 2027, a deadline beginning 2027.

We know that is December 2026, but I don't expect any member states to deliver on 24 December wallet solution. Yeah, with that, I think I'm done. Thank you very much.