Signing with the EUDI Wallet [Advanced]

Hello, everyone. I'm Viky Manaila, Trust Services Director with intarsys Group and Cloud Signature Consortium President. Together with me today is Thomas, who is Vice Chair of the Technical Committee in Cloud Signature Consortium.

Thomas, if you want to introduce yourself, please. Thank you. My name is Thomas Pielczyk. I'm Head of Product Management at Procilon Group and have been around with the Cloud Signature Consortium, driving our signing standards for the past nine years, and I'm really happy to be here with you today.

So you have seen Adrian's demo with the wallet, how simple you can open a bank account, but what is the technology behind and what are the specifications that you have to build your solutions to be able to generate in such a simple way digital signatures compliant with the legal requirements when Cloud Signature Consortium are taking care of.

So, in case you haven't heard yet about Cloud Signature Consortium, we are a standardization body, a corporation established back in 2016, having members more than 70 organizations from all over the world, contributing actively to specifications with an open source license. We have also liaisons collaboration with Etsy, and based on this collaboration, our specifications are referenced in the corresponding technical standards 11942 regarding remote signature generation.

Last year, we have released the second version of the CSE API specification, but we are continuously adapting, working, evolving with the requirements from the UDI wallet and market needs to generate signatures with the wallet. We are also preparing CSE certification program soon. What does it mean? In case you have a solution that is compliant and you have implemented the CSE specifications, you have the proof to certify that your solution is specifically compliant with the specifications and with which part of the specifications you have implemented.

As you probably know, CSE specifications were referenced in the Implementing Act for integrity and core functionality of the UDI wallet, so meaning every relying party that wants to implement a signature flow interacting with the UDI wallet must be based on the CSE specs version 2. The majority of our members are contributing, are developing in the four large-scale pilot use cases for signature generations. You have seen the banking account opening.

We are trying to pilot as many use cases that are meaningful for the citizens, because if we don't develop meaningful use cases, they will not adopt the wallet. We know that member states are mandated to issue the wallet, but the citizens are not obliged to adopt them. So a lot of use cases that are requiring also the electronic signature, because we know we always need to sign a document at a certain point in time.

So no matter the technological evolution, we will be required to sign here, and we have to be able to put the users and the citizens in the condition to sign with the wallet, of course. It doesn't matter if the wallet is a new UDI wallet, is a wallet from other geographical jurisdictions or regulatory requirements, the specifications can be implemented equally. You have seen and heard a lot about one of the biggest events that I'm so excited to be part of, the Global Digital Collaboration that Daniel Goldscheider had the initiative to organize in July in Geneva.

Cloud Signature Consortium is co-organizer, and we will have two events where we will discuss digital signatures, so not EU digital signatures, but global digital signatures use cases, because this is a global event, so it's not EU-tailored or geographical region-tailored. And the point is to have alignment between different high-level representatives, standardization bodies, to not end up in a silos of wallets and digital credentials. And the second event is more EU-oriented, related to the trust services and the importance of the service providers in the UDI ecosystem.

So join us in case you haven't registered yet. Now I'm inviting Thomas to continue. All right.

Thank you, Vicky. And I must say a really tough baseline coming from Adrian with all these simple things or things looking that simple regarding the UDI wallet. If you have been attending the other tracks of UDI wallet-related events here, you should certainly know that there is quite a complex ecosystem behind all this stuff looking that simple. And this ecosystem becomes even more complex once you combine it with a second one, with the signing ecosystem, because from a user perspective, the vision is clear. You've got your smartphone on your hand. You've got it in your pocket.

You've got your identity. You've got your signature within. But once you expand all the features and requirements behind that, you see that you've got two really heavy, complex ecosystems to be combined. And we at the Cloud Signature Consortium want to facilitate the signature part. We see there are very clever people involved in the UDI part. We've been around with the signature part for the past nine years, since 2016. And we have been facing a couple of hurdles to overcome.

And for the part where we really want to implement the vision that we got the signature in our pocket using our UDI wallet, we have to be aware that there are regional regulations to be overcome. We got our local regulation here. Local means European for us here and today. But if you got the vision from a keynote yesterday, then we see UDI can be global. And it's a blueprint. Everything that we do in Europe is a blueprint for people all over the globe. And the same is a fact for signing. Having started as a European association, we are now acting globally.

And this is where two really important facilitators for ecosystems come together and can create a real win-win situation. But in order to be successful in this regard, we need to concern that there are business domains with specific needs, that there is a diverse IT landscape built on diverse requirements, but also on common standards provided here in form of the architecture reference framework for the UDI wallet. And it's complementary standards like open ID, open ID for VC and so on.

And beyond the technical and business needs, we also have to see that for an ecosystem to thrive, we need to make sure that all the participants, and this is also the vendors within the ecosystems, have a chance to create their value propositions to differentiate and to sell their USPs. So coming from the vision that everyone has everything freely, we still need to build patterns and standards which address also the latter need. And this is where the CSC standard comes into play. We've gone through all this with the signing domain.

We will certainly experience similar issues within the identity universe, and we will combine them to a common standard and to a common solution. How can the CSC standard facilitate this?

Well, what we see here is a standard picture from our standard documents, the CSCI specification. What you see here is a glance at a high-level overview of our ecosystem in the signature domain. And the CSC standards sit here between a signature application and a remote signing service provider because, well, as the name gives it, we are pretty cloud-central. We are not handling any local smart cards and so on. And we are providing remote signing standards between a signature application and RSSP.

So the challenge for us and for the URDI wallet here is now to combine all the ideas here and the standards we have at hand to fit into an overall picture. And there are currently two approaches how we can interact with the wallets.

For once, if we take the wallet as a simple ID provider with high-quality standards, then we already have addressed this element within our core standards. Because apart from providing the basic APIs between signature applications and remote signing services, we also facilitate the adjacent interactions between all the related actors. And an UDI wallet essentially is an ID provider to the system and to the interactions occurring within the system. In this approach, we call it a provider-centric approach. Everything remains as it is.

We got our business applications talking to signature applications. These are talking to remote signing providers. And somewhere therein, there is this nitty-gritty piece of UDI wallet.

Secondly, we got a wallet-centric approach. In this approach, the signature application is completely held within the wallet. So we got a real one-stop solution with the wallet where any application can directly access a signature application on the wallet using the specific profiles, which are typical there. It's OpenID for our VP. And let the wallet handle everything behind that. So two different access points.

And regardless whether you are already implementing the CSC signing standard to get into the signing ecosystem or whether you are right now adopting the UDI wallet using OpenID for VP, because this is currently the shooting star in our EIDAS environment. Regardless of those two issues, you are just one step away of having a remote signing solution which is wallet-based in your pocket. How does the CSC API provide the elements?

Well, in the end, first of all, at its core, it's just a web API providing elements for discovery. So we've got some endpoints enabling any integrating party to discover the features and the standard versions and so on of the CSC's provider on the other side. It provides authentication and authorization means. We just saw that this is a point where an UDI wallet might interact with the overall system. We got endpoints to look up, to list, to inspect credentials. Credentials is the term used for your key certificate pair used to sign.

And in the end, we got our endpoints and standards for executing signatures in various flavors to really satisfy the previously mentioned business needs of, let's say, having a really integrated approach or a pretty high-level approach, just sitting on your documents to be processed by any services out of your business. Timestamping comes as further evidence into play, a major cornerstone in all the processes and mostly already integrated within the signing process itself.

So, again, how does the UDI wallet come into the play? First of all, it's really a means of identifying and authorizing something. So it's on the authentication and authorization track of our standard. The CSC standard features a couple of proprietary authentication means to satisfy pretty basic needs or, let's say, the Pareto 80% needs you see out there. But there are also heavily standard-based, open-based approaches which rely on OpenID and OAuth2. And within this authorization ecosystem, we got, beyond this simple personal identification aspect, a couple of aspects to be covered.

Because, apart from the user himself, we still have a party like the operator of our signing application. We typically got business relationships between the operator and the signing service. We need to add this level of authorization into the overall picture. Then it comes to credential authorization. This is the part where the user really interacts with the system and says, okay, I want to consent to the signing process and to signing this document.

Within this credential authorization, we got two major options, the inline authorization within our protocol and then the delegated authorization regarding OAuth2. And this is actually something where UDI Wallet, with the architecture framework and the related standards based on OID4BP, comes into play. And this is the glue here, the exit which we already have in our system. Account tokens being a further part where a user organization might convey further partnership in the form of SaaS offerings.

So, all in all, we've got the components to really implement the key requirements and the key vision elements, which you can take from the architecture reference framework and the ideas behind it. And with our robust API for remote signing, with the already there features of supporting pushed authorization requests, rich authorization requests to convey transaction data as required by the UDI Wallet. And by providing various flows which keep the overall system open to integration within your business context, we have the basics. We build on open standards.

And while we use these open standards, we define specifics for our use cases within common data models, which now complement our core specification in separate documents. So, I will just skip through this and point out that the overall specification really consists of these two core resources right now.

For once, we've got our standard document, which defines the API, which defines the overall architecture, as we saw in the slide we found at the start. And as an extension, the data model to really ensure that everything fits with the standards which are applied within our ecosystem.

Okay, so we actually still go beyond this mere standard. We go to a complementing technical community.

So, once you want to really get deep insights into the standards and get involved, you get access to the technical community, which will help you to integrate this already simply integratable standard. And beyond, we will provide conformity checkers and a certification program, which supports you or supports especially the provider side, ensuring that a remote signing service provider can really participate in the overall system and in the future also leverage the UDI Wallet.

And this being all these components will lead you to the goal of successfully integrating the signing process and in the end to, let's relax again, to a use case, which we will show you. Here is actually a recording of an implementation based on the reference implementation wallet, where a user wants to open a bank account or to apply for a loan and needs to sign. We know that most of the users are struggling in getting a digital certificate prior to engaging in any kind of signing transactions.

One of the main leaps of the UDI Wallet is the possibility to sign directly without the need to have prior to that a digital certificate issued. Here, the signing experience is with an existing signing certificate, but at the same time can be generated on the fly. It's a very short video. Let me check. Yes. So the user is checking the document, is visualizing the document that needs to be signed, is continuing the signing with the wallet, is reading the QR code and confirms the signature generation. That easy.

Really, it takes seconds. We have seen from the Adrian demo before. So this is it. Sign a document with the wallet in 10 seconds. You can download it. You are automatically redirected back to the bank website and you can continue the flow. Thank you very much. In case you have questions, please otherwise get in touch with us, consult our website, download the specifications and contribute with your comments. Thank you. We are a minute over time, but anyone has an urgent question about digital signatures? Yes. Yes.

I'm not sure how urgent, but I just wonder if you could talk a little bit about key rotation, especially when it comes to things like non-repudiation. Well, actually, the key rotation aspect is typically one which is already handled on the provider side. So regarding the system you just saw and the actors involved, everything regarding key rotation is managed by the remote signing service provider, by the QTSP, and generally independent of the overall signing ecosystem.

We certainly have to reflect on how to facilitate this process within the wallet where your credential representations are held and somehow bound to the decentralized component on the provider side. But this is nothing I can really deep dive in now. If you don't mind, may I share one thought and remark?

I myself, I support the corporate remote signing solution for corporate in seven countries. One thing maybe we lack as industry here with signing, we discuss a lot of details and that stuff is really relevant and important. But we maybe fail to remember this all matters only like ultimately for lawyers, like the end customer is lawyer here, the legal person. Because the main question is, will you feel comfortable going with this signature to the court and protect our interests? That's the main question we have to keep in mind. They must be asking us, so guys, equip me with the proper tool.

And I believe we fail to address and to be like IT version of Max Rams going to legal conferences and explaining this trust model. Because the question I get most often is, can we use this signature or this signature or this signature? The lack of understanding of the trust model is the key. And we look freaks to them when we discuss these things, important things. But the major, there's a gap we need to fill. That's my point. So I wish we can address this. It would help everybody here, I think. It's part of the market awareness and education, of course.

And it's our parallel effort that we are doing in order to educate the market and to explain exactly what are the requirements, the benefits and the compliance part. Because it's not easy to accept. So now you can imagine with the wallet in the middle, how big the questions will become for legal department. But it requires passions and patience and a lot, a lot, a lot of education. And we need all the community to contribute to awareness. Speaking of patience, we have our next speaker patiently waiting. Thank you very much again. No more questions for the rest of the afternoon.