 Well, hello everyone. My name is Fernando Marino. I'm from CEPICU-D and I'm here to talk about the centralized identity framework for Internet of Things. Actually, it's a lab. It was a research that to develop the CEPICU-D. CEPICU-D is a research center in Brazil. Okay, we are we are researching blockchain applications and the application of self-survival identity for people and things as well. Well, a little bit about the Internet of Things that you know, Internet of Things is a network of things, a network that connects things and those things should be identifiable. The Internet of Things is what differentiates each of the IoT devices within the OCC systems. It is about how to identify a specific device in the ecosystem. Okay, so here is an example of IoT architecture using self-survival, decentralized identity. This was a concept, a common concept of architecture. You know, you have here the applications, the business applications layer, then we have the cloud servers and the wireless network, the wireless sensor network, okay? Here in the in the middle of that we have the IoT midrars, where those IoTs usually connect themselves and send their data for those midrars. Okay, we have a few challenges, you know, in the IoT field. Devices, devices usually they are limited in terms of computer power. Devices can be compromised and then forced to propagate invalid informations. So we are not sure about what we are receiving from those devices and interoperability among the different networks and the guarantee of authenticity and integration and the integrity of the data. How to ensure the integrity and authenticity in an IoT network using self-survival decentralized identity? Portuguese is decentralized because of that is IDG. Here is a concept we developed on CPQD. These frameworks basically we have a security layer. We have a midrars, that's a midrars called DOJO, it's an IoT midrars. It's an open-source project that's a PQD developed a few years ago. So DOJO is an open, we have a community and a lot of industry using DOJO in Brazil for Internet of Things, blockchain layer using Hyper-Edger Indie and we have a lot of ACAPI. I mean we are using ACAPI to run the agents of issuers and verifiers, but to run this lab you also use ACAPI embedded in the devices. Okay, so we got raspberries devices and we put ACAPI running in these devices here. And we have a lot of sensors connected on those devices collecting data and then transmit those data as ACAPI as raspberries working as a kind of hub. Here you have a few examples, for example, one ACAPI one, sorry, one raspberries working as a hub before many sensors. We have one sensor connecting one ACAPI using through the raspberries and we have an IoT using an ACAPI directly. Okay, the idea here, how it's working, we have to change the ACAPI to accept the MQTT protocol. Everybody here knows the MQTT protocol, IoT. Okay, so that was the new implementation here. It was to adapt the RS CloudHT Python to transmit data using MQTT. So how it is working? Well, the sensors collect the data. We wrap these data using GDCOM protocol, using connections, and then it is sent about using the MQTT protocol for the agent. When it's come to Dojo, Dojo can check the GID information and the signature of those data that was sent using the GDCOM protocol. Okay, so we have a kind of trust layer here to guarantee to the mid-word that these data that they are processing now came from this specific sensor, this specific IoT. Okay, you can use the engine as well to exchange credentials. One idea that I have here was to share a particular IoT. I mean, a lot of midwars here using the same IoT to collect data, but the IoT must know if this midwars is allowed or not to collect their data. So the owner of the IoT device issues a credentials for the midwars. The midwars show those credentials for the device. The device check it, verify it on the ledger, and say, okay, you can receive my data now and start to share this data with another IoT. That is particularly interesting in the field of 5G write because at least in the development countries like Brazil, the telcos, they must to share their devices 5G or it should not work properly. The security layer is we are using the common security approaches to guarantee the security information and how I will explain a little bit more about architecture now. So as I told you, we use Dojo platform, Aries agent, and IoT device. The roles of each one, well, the Dojo is our IoT midwars, as I said. It establishes the connections and issuing credentials through our Aries agent and finally the information is coming from the device and is accessible in the web platform. Okay, Aries agents are decentralized agents here. I think we don't have many doubts about that. And the IoT device is properly the one that gets information and data and transfers those data for the midwars using DidiCon. Our proof of concept goes, where was our goals? First one, evaluate the framework developed in a test environment. It was build a lab. Detect the flaws and possible improvements in the concept and even in the application and define a feature work for this research. And present the conclusions. Okay, that's the sequence that we have. So we have the agent. We have the IoT agent, I mean the IoT embedded agent, the Dojo agent, a cloud agent that's integrating with our platform and the platform as itself. The IoT agent create a request of connection. The Dojo agent accept this connection response and offer accreditations for this device. Since it's offered, the device accept it or not. Usually it's accept our accreditations and send a message. Use the send the message protocol. Everybody here knows the send the message API in the Arizac API where you can send a string for another agent, a free string. You use it to transfer data. So it was a real lab. In production we have to develop an appropriate channel to send those data. But here, only to try, you use the send the message API. Rest. We send the message. The agent handle the message. And why the Dojo agent handle the message? Because we developed Webihook here. And we are checking the strings, detecting the strings. The kind of those messages. I mean, it's a set up message. It's a data transfer message. So we developed a protocol to detect the kind of message we are receiving from our IoT device. So we handle the message. And then we send the message to the Dojo. Here is the Dojo. We use the container. The container is the version of the Dojo platform. It's open. So everyone here can try the Dojo. We use a local in the network. Using the Vole network to test the solution. The Arizac API that we use is the version 1.0. 1.7.0. We use a Hasbari Form Auto B. A Hasbari Pi OS to desktop operation systems. Arduino and a sensor to collect the weather. Informations. Okay. That is our test bed here. So we have our Hasbaris and the sensors connected to the Hasbari. This Hasbari has an Acapai agent embedded on it. The difference is here. In the settings of Acapai, we will have to set the MQTT broker configurations. Okay. So we have a broker on MQTT. And we change the Acapai to receive these informations and to use MQTT as its main protocol. Okay. Since that we have a script to collect data. I mean to collect the data sent from the IoT devices. And we have the Dojo platform receiving the data from the devices. Like pressure or temperature. Okay. Now we have a video to demonstrate it's working. It's not working. Even with video, demonstration is not easy. Well, I'm so sorry guys, but I think it's the video. It's not my computer because I don't have the HDMI in my own one. And it's not playing here. And I don't know exactly what's happening. Sorry about that. That's a nice video showing the setup of the Aries Cloud JGT Python. The IoT connecting receiving its credentials from Dojo. And then send data to the Dojo and the data showing in our platform web and working. But I think yes. Good idea. Thank you. Thank you so much. Well, here we go. We're starting the agents, the sensor agents in the API Python. Okay. We created the invitation here as you can see in the terminal. We created the invitation. The invitation was created by the IoT agent and it was sent to the Dojo agent. So it's interesting because the IoT must know the endpoint and the address, the presence address of IoT mid-war here. Now the connection is okay. It was established and the IoT got its credential. In the Dojo, each device works like an agent. So we can see here the device that was connected here. The device that was connected. Now you can check the device, the device, and the data coming from this device using MQTT protocol and DDCOM protocol as well. The data coming from the device and being verified and showed by the Dojo platform. Well, what we learned with that are conclusions. First, based on this prototype that we developed, it's possible to state, IDD decentralized agent can be significant to IoT security. DDCOM has an interesting layer that provides messaging integrity to guarantee that the content that was sent by the device was not changed by itself. The creation of virtual devices of digital twins associated with digital identities and MQTT transport plugin for interoperability in IoT networks. Second, finally, we obtained an unstable test scenario with the possibility of extensions for another applications. Future works, that's our vision, right? The image that I've shown you, show you how it was in terms of a POC. Looking for future work, there's a lot of things to do, as you can see. First of all, we have another protocol that must be integrated with the Aries, not only MQTT, but a lot of one and others. We have the perception layer, because we don't have in this POC the perception layer. I mean, we are using the connection layer, the hub layer, using Hasbar here, but in terms of security, we have to connect in the perception layer. I mean, even put a DIDD into the sensors that you connect in the hub. Interoperability, interoperability among things and among platforms as well. Connect with another platform, another midler. We are only working nowadays with Dojo midler, but it's necessary to integrate, for example, Bosch has its own IoT midler, and it must be integrated here to use this protocol as well. Police management, we are talking about governance, for example, to create a trust layer here. We are not only talking about technology, but we are also talking about how we can create a trustable environment for companies and agents. So is that. That was, we developed, and in CPQD, using the IoT, our lab that we developed there. And that's the insight, the landscape that we have to use decentralized identity with IoT. Anyone has questions? Yes. Yeah, no, we didn't run in the Arduino device. We just, we only use the HaspBerry and Arisklight Cloud Python agent. I mean, I don't think it's possible to run the ACAPI in Arduino because it doesn't have support for Docker or something like that. And in this research specifically, we are more interested about the protocols. Okay, how to interpret it? Because at the first time we have a doubt. It is possible to use, because MQTT, it's a very short protocol. And the DD-Cone, as it is nowadays, it's not exactly a teeny protocol. It's a heavy protocol, I mean. So it works with the MQTT protocol. I got myself surprised when I see that it's working pretty well with the MQTT protocol, even to do proof of credentials, issuing credentials, not only to send a message rapid in a DD-Cone protocol. That was a surprise for me. And so we are looking for that, but it's clear for us it's necessary a light version of the DD-Cone protocol for IoT devices. So we are not looking to run in Arduino or something like that, because we are researching the protocols among those devices. Actually, it's... Yes, sure. We have a picture here. I hate animations. Here. We have seed, label agent. Here. REC, because it's... Here in the Genesis Urali, it has the address of our VOL network. So we build a VOL network in-house for this lab, and it's connecting everybody here is connected and registered in the network. I don't know if the right thing to do. I mean, the device, they don't most be registered in the ledger, right? Only the issuer actually needs it. But we registered the devices and the verifiers and the issuers in the ledger. So everybody here is registered using a seed and something like that. But it's pretty similar to what you do when you set up a cloud agent to ACAPI. Oh, I got it. Yes. The engine integrations, it is... You know, we are using the RPC. I guess it's not... The engine integration is not happening using MQTT protocol. That's your question. It's not... No, no, no. The engine integration, we didn't handle it. So the engine integrations is still using the HTTP protocol, as you can see. We're not using the MQTT to integrate to the engine, but that's a great idea. Yes. That's a consideration on matters for this research, absolutely. Thank you. Okay. It's lunchtime. Thank you, guys.