A trust module for the interaction with virtual characters

Abstract

This paper describes the architecture of a trust module for the interaction between human users and virtual characters. The module is part of a bigger project whose goal is that of creating virtual and truly realistic characters capable of interacting with human users. An example of such a virtual character is a computer rendered museum clerk that interacts with visitors. The role of the security module in the envisioned scenarios is that of providing trust, mainly regarding the identity of the human user, but also about the "identity" of the virtual character. In this paper we design (and describe the implementation) of an architecture in which human users identities are checked through face recognition and handled with verifiable credentials managed through a public blockchain. The project has been funded by the European Union and is under realization.

DSMAC: Privacy-Aware Decentralized Self-Management of Data Access Control Based on Blockchain for Health Data

“…Following the Self-Sovereign paradigm, the digital identity of the user is kept in a digital and private wallet. To this end, the DSMAC framework includes a component which is a mobile app through which the user can manage the wallet and at the same time he can interact with the security of medical data using an encryption scheme and the user's SSI wallet [59]. For this purpose, a ZKP cryptography technique is adopted to address specific requirements focusing on data privacy A ZKP is a kind of cryptographic method, and its use in blockchain appears to be promising in cases where existing blockchain technologies can.…”

“…To connect to the Indy network and control different nodes, we have utilized the Admin UI from the VON network repository [59]. It initiates the blockchain with the genesis block, a server, and 04 nodes.…”

“…Those agents are written in Python by using the open-source Hyperledger Aries Cloud Agent Python (ACA-Py) library. It will be also run over Docker, as shown in Fig 13 . ACA-Py provides all of the core Aries functionality such as interacting with other agents and the ledger, managing secure storage, sending event notifications, and receiving instructions from the controller [59]. Thus, the ACA-PY component is necessary to securely deliver medical data from the wallet to the F2C infrastructure, and for each agent, the sender explicitly adds another layer of encryption [59].…”

“…The Aries infrastructure offers: (i) a blockchain interface layer, (ii) libraries to implement cryptographic wallets for secure storage of cryptographic secrets and other information, (iii) an implementation of ZKP-capable W3C verifiable credentials using the ZKP primitives found [59]. The initial idea was to create a front-end tool that uses an API to interact with ACA-Py without the need for its database.…”

“…ACA-Py maintains its keys and requires the controller application to create schemas, credential definitions, and revocation registries, as illustrated in Fig. 15 [59]. Also, the ACA-PY provides a queue to hold messages until the mobile agent requests them because the mobile wallets are not online at all times, and are not constantly polling to see if they have any incoming messages (that consumes resources, particularly data and battery, on the phone) [59].…”