We wanna introduce the topic of cloud signatures and the CSC standard and the consortium. This talk will be in two parts. So I'm mentioned director of DET, trusts and board member of csc. And I'm gonna present a little bit about the IDAs environment and why CSC is so vital. And then Luigi Rizzo from info and the chair of the technical committee will explain a little bit of technical details. So sadly, he's taken a little ill, so he will be presenting remotely, right? So, so of course digital is, well probably at this conference, there's no need to explain about this, but it's clear that it's, it's going gonna be one of the main focus things that the European Commission is looking at. And of course we know digital identity is at the core of that, and the trust services related as well. So it's clear, this is a topic that has been around for a while and is of course now a big topic for the com for the commission.
And of course, you probably heard about this, there is a so-called IDAs regulation that regulates electronic IDs, authentication and signature. And this has been around for a while, has already been regulating signature and other things. And there's currently a revision going on. And this revision is, is adding new things, but it's also adding the topic of the so-called digital identity wallet, which will be a, a new central component containing your personal ID attributes and a link to other trust services. So you already see it's, it's more than a single minded servicing, is really in an ecosystem of trust services. And the wallet will play a, a vital role in this. So of course, it's clear we already have digital identities. We probably have more digital identities, and we need, so the question is how, how can we build a system that maybe reduces this? And of course also adheres to data privacy and all this, this type of things.
And the identity wallet that the commission is proposing right now is, is, is trying to do exactly that. So it's gonna be a mandatory thing that a digital identity has to be provided by your local government. And of course, even under the, the contract that the European Union is set up with national identity will still remain national identity. But of course, the topic here is more that there should be a common way of, of storing this, of, of dealing with attributes and to make cross border services possible. And this is exactly what the wallet is aiming at. And it's really part of an, of a general ecosystem. And of course, you, you may have heard of other regulations as well, digital Market Act, digital Service Act and other things. European has data space. So there is a lot of initiatives coming from Brussels right now trying to set up a digital ecosystem and a trusted digital ecosystem.
And of course, this is also strengthening the, the general buzzword of digital serenity for the European Union. And so here, here is just a quick overview. On the top, you'll see the classical stuff that has already been regulated in the, in the old regulation, especially signatures, remote and other things, seals, which is the equivalent of signature for legal persons. And we have new trust services at a station of attributes, probably one of the most interesting ones. So the one thing is always about who you are, your personal identity, and the other thing is what you are. Yeah. So, and of course, typically who you are should be just one person, at least in the normal case. But what you are can be variety, different. Yeah, you can be mentioned director, it can be a doctor, it can be both. And you have private commitments. So, so that's an interesting thing.
And there are other things coming up. So basically this is just showing it's a, it's a full ecosystem of, of things. And why is this relevant time-wise? Well, you see that this is the timeline that we are anticipating right now. So at the moment there is a so-called trial log happening in which the European Commission, the European Council and the European Parliament is more or less arguing about what the final text of the regulation should be. And we, we, we still hope that it's, there's going to be adoption in the second half of this year, and then there will be implementing acts, and then there will be a commitment in an implementation deadline within a few couple of years. So this is basically shows it's, it's, it's wildly relevant. So, so now looking, looking at the, the general architecture, you can see there are different components.
When you look on the, right, on the left hand side, there is a so-called P i d with the personal identification data that typically comes from, from your local government. And then there are attributes, this is more related on the, on the lower left side, they can, they can come from authentic sources or from some so-called non-authentic sources. The authentic sources can go directly into the wallet typically. And the so-called non, non-authentic sources, they have to go via so-called Q T S P, a qualified trust service provider to make sure that there is proper validation and issuing. And all this culminates then in the, in the wallet that is on the mobile device of the user. And of course there are, there are more services related to signing and ceiling. And so the question now is where does csc, where, where does cloud signature come in?
Where does INTERABILITY come in? Well, it's come, comes indirectly at this point because, so interoperability of course is one of the core things. Yeah, you just don't want multiple different technologies implemented. You want cross board or interoperability. And I would say that for, for the P I d, so for the personal identity and the attributes, there's already a lot of work going on, a lot of discussion. But for the signature part, there's really not so much discussion on the commission level. And we from the CSC think that this is a great opportunity to, to to, to look at what's already there. So what type of standards can we already use? And we do think that CSC is here, very important contribution to this. Not, not only on the European, not also on the global level, and why do we think it's so important to, to make this happen with the wallet?
But here's a simple, simple idea. So of course when you look at trust services in terms of signing, the signing itself of course is one thing, but of course identification is, is, is probably the most important and the most costly part in this. And of course it's the wallet really contains your p i d. Then of course, identification and authentication can be, can be subsidized into one activity. So that basically you have a one stop shop in this, which would be great. And of course the identity will be provided on, on a high level of trustworthiness. And then of course once it's inside, then of course you, you can simply, you can simply use, use the volatile to, to, to, to make it work. So we do, we do think that inability for, for trust services and especially for cloud signing, will play a vital role in the acceptance, in the success of the, the new digital identity wallet and the corresponding ecosystem. And so basically we, we do think that on the level for, for the cloud sign, the CSE already has made substantial work and substantial progress, especially to this key parts of harmonization and, and operability. And with this, I think I would like to hand over to Luigi who will give you some more technical input now on what the CSC has been doing. So let's hope that this works remotely.
Luigi, hello.
Good
Morning. Fantastic. I
That you can me. Okay. As I said by, by Kim, the protocol of CSE was intended to simplify to the, the experience of digital tors and to, to build a model of API that every client application can use from different providers in such a way, there is a possibility to enable secure sign transactions through every devices your web browser in a PC or your mobile device from your desk on the, on the tablet by using a tablet on the go. And so every user can easily sign document store in the cloud with any device. There is no complex procedure for renewing the certificate. No risk to to, to lose token or smart or to be or, or, or to, to, to, to, to lose these, these devices. Next slide please.
Okay. This is a typical architecture of remote performing, a remote senior senior creation. As you can see, the designer can interact with the senior interaction company. That that can be, that the wallet itself, that can start the, the, the designing transaction. And then this component can interact by using the api standardized by cloud consortium with the remote service operating the, the senior creation that is usually operated by a qualified trust service provider, generally by a trust service provider. There is a design application that can interact with the crypto module and all the parts can be certified by using standards requirements that are developed by c i n, the number, you can see the numbers of these standards. And this architecture shall interact for authenticating and users that, that ask for senior creation and also for authorizing the creation of the senior. And the, the interaction with the, the wall will be very important also for this kind of authorization and authentication functionalities.
Then there is also the part for of registering the, the, the user data for issuing the the certificate. Next slide please. And this is, yeah, just a list of the main functionalities that are in the, in the standard. The next four or five slides will detail all these functionalities. Next slide please. The main, one of the most important things is the possibility that data client application can ask for the characteristics of the signing server. The PI specifies a list of function, but obviously any provider can implement all these functional or only apart, and this API can provide information which kind of implementation was, is performed by this service. And above all, the most important thing, the list of all API method that are implemented and the all theup, the, the authorization and authentication mechanisms that are supported together with other information that are not, they say so important for the functionality. This next slide please. So after having a, a clear idea of what is provided by the remote signing server, there is a possibility to obtain information about the signing credentials of the user that wants to perform the, the sys creation.
And so all the information needed for requesting the senator, for authorizing the senator, for selecting the, the certifi, the design certificate that the user want to use can be obtained by the client application. And next slide please. In order to, to request the authorization to create this ator, there are a certain number of possibility that can be implemented. There is a challenge responsible mechanism. There is wild mechanism by which the, the designer can authorize the senior without providing any information to the, to the client application to which the signer is interacting. There is a possibility to pull authorization state by the grant application, not that to, to be able to, to know when the simulator can be requested to the signing server provider. Next slide, please. As I said, there is the possibility by using route two to perform these authentication and the authorization functionalities.
After that, the simulators can be created and the next slide will show the, the PI for creating the simulators after having performed all the operations for selecting the science certificate for authorizing the usage of the private key. And so finally, the client application can request the cation to the remote signing server by using, by, by providing the documents, they will documents to be signed or the, the of the documents to be signed or directly the, the senior to, to the, the issue to be signed. And when providing this information as different senior formats can, creation can be requested and so on. And the next slide will show an example of a flow that is using out to two authorization for creating some s or only one signature. The user can request the, the senior application to, to sign a document. Then the application request to author to the authorization server.
The, the token needed to, to request the application to the remote service authorization server. By interacting with the user can create this token that is possible to the senior application that after data can request the senior education to the remote service by using the OC api. And by pressing this token, this senior activation data is, is technical name to the remote service. And, and after that, after receiving the printer can provide, they sign the document or documents to the user. This is the last slide. The next one is just for yeah, remember some where the, the, the, the standard that the PI specification can be downloaded and if there is any interesting contributed to the development of this specification. Yeah. I encourage all of you to, to, to become a member of the consortium and to get in touch with the consortium. Many effects for your attention. For your attention.
Thank you.
Okay. So, so maybe summing up, we wanted to display a little bit about the importance of IDAs for this upcoming ecosystem and also about the maturity of the cloud signature API and the things we've been done. And we do think it's highly relevant for what we will see in the next upcoming years, especially maybe also in the large scale pilots where the ida's functionality will be proven to be capable. Thanks very much. Yeah,
Thank we have some time for a couple of questions If you have any questions we could. Alright. All right.
Well, excuse me. I must admit I'm very impressed. Good. So I'm from Australia and we need, I mean realistically, I dunno whether Graham's still in the room here, but, well, I reckon the Australian government needs the, the cloud signature Consortium in Australia cuz we are grappling with this very issue.
Okay,
Good. Australia, I mean, basically a number of years ago, Australia decided we, we needed a, a digital health card. That was the concept. Okay. And, but unfortunately the privacy lobby got heavily involved and it was decided that the citizens would never allow a digital health card. So that got knocked on the head. Now there's suddenly a, a realization that what we really need is in effect a electronic identity card. Yeah. But so, and, and what's really needed is the ability to deliver government services Sure. From the federal government. Yeah. Interestingly enough, services delivery in some state governments, they already have these capabilities, but what we don't have is we don't have a, a digital, a wallic. We don't have a digital identity service in Australia. Sure. I think you guys should, if you're not talking to the Australian government, you should be. Okay.
Well, our president is also here, so maybe you can, you can speak with her as well. She's right over here, so maybe we can, we can have a quick, quick contact right after this if you're free. Thanks very much.
Yep. Thank you. Maybe we could have another question. What is the technology behind the temper protected environment to make it absolutely secure.
Absolutely secure. Okay. Well that's absolutely secure. So I mean, so, so as you can, as you have seen, I mean it's, it's, it's a server-based architecture. So of course key materials inside HSMs and all this stuff is, is certified. And of course authentication is also playing a vital part in the, the authentication part, of course also have to be certified. And as state of the art, I would say I would, I would have some doubts if we would feel, feel able to make a statement about absolute security. I think it's, it's something that we all want, but we'll never get.
Yeah. Kim, can you show the slide where there is the architecture of the, the second slide of, of my
Part? I think it's all in
Which, yeah, in which the justifications that are requested.
No, I, I can't.
Okay.
So Cause the next slides are already up here.
Okay. Okay. Okay.
Yeah. Okay. Another question. Do we have time for another question or no? No, we'd have to take it offline. Thanks very much. Okay. Thanks for being here. Thanks Raj. Thank you
Ola. Thank you Ola. Have a nice day. Bye.
