## 4 Results: Proof of Concept
### Identity Management Implementation
#### 4.1.3 Verifiable Presentations (VPs)
To facilitate this, the link is converted to a string for transmission and then converted back to its original type upon receipt. This process is essential to establish true communication and to verify the identity of the subject when necessary. Because Verifiable Credentials may contain sensitive data, they cannot be published on a public ledger in compliance with GDPR, as outlined by W3C standards. Instead, these credentials must be stored securely in a digital wallet. However, due to incompatibilities between the IOTA key management library and the Raspberry Pi, the credentials were temporarily stored on the device in plain text and JSON format to validate their functionality in this implementation. Figure 3 shows a flowchart depicting the interaction between author and subscriber during identity validation and channel setup. The steps are explained below. 1. Channel Initialization: An instance of the trusted entity (author) was created along with its associated channel and publication. Similarly, an instance representing the subscriber, in this case the Raspberry Pi, was also set up. Once the channel was published, the subscriber received the publication link and attempted to subscribe to the channel. Upon receiving the subscription request, the author validated the subscriber's identity by verifying the associated credential. 2. Identity Validation: If the credential is successfully verified, the author accepts the subscription and sends a keyload message. This message contains encryption keys that define which participants are authorized to publish and receive messages on the channel. Only subscribers included in the keyload can decrypt the encrypted messages. Conversely, if the credential is invalid or revoked by the issuer, access to the channel is denied. 3. Message Encryption: Once the subscriber gains access to the channel, it can act as a publisher to send or receive messages. The messaging system operates similarly to the MQTT protocol but with enhanced security and decentralization. Messages consist of a public payload, analogous to a topic, and an encrypted payload containing the secure information to be transmitted. Messages can also be signed with a digital signature linked to a public key known to all authorized users through the keyload mechanism. This ensures that only users with the appropriate decryption key can access the encrypted information, maintaining message confidentiality. ### Challenges and Limitations

#### 4.3.1 Protocol Integration

One of the major limitations of the IOTA Identity Framework is the lack of integration with the DIDComm protocol, which limits the ability to simulate real-world interactions between the various roles in decentralized identity management. DIDComm is a protocol designed to facilitate secure communication and data exchange between Decentralized Identifiers (DIDs) and other entities. Its absence in the current IOTA framework means that simulating role-based interactions--such as those between issuers, verifiers and holders of digital identities--remains challenging. In addition, the DIDComm protocol is not yet adapted for lightweight devices, limiting the ability to deploy IOTA Identity solutions in resource-constrained environments. This is particularly important as IOTA aims to extend the usability of decentralized identity management to devices such as IoT devices or microcontrollers. Figure 3: Flowchart between author and subscriber. #### 4.3.2 Resource Constraints

The IOTA Identity Framework is not currently optimized for low-resource devices such as the Arduino Nano 33 IoT board. Developers within the IOTA Foundation have focused their efforts on other aspects that they believe will bring greater value to the ecosystem, such as decentralized finance (DeFi), NFTs, and digital identities primarily targeted at individuals. As a result, the framework has not yet been tailored to work efficiently on lightweight devices. This limitation became apparent during performance testing.