Creating Device Identity using Hyperledger Indy

Introduction

Identity is the genesis of any operation of an IoT device. Without the device identification, the management and interoperability of IoT devices is not possible. In addition, the distributed nature of IoT makes centralized IoT solutions irrelevant. DLT architecture is a perfect fit for creating identity for IoT devices which are self governed. This gives devices and users of the system a complete control over their identities, at the same time enabled secure interaction between any two entities. Hyperledger Indy provides a self sovereign identity ecosystem based on DLT technology enabling secure and verifiable trust. 

...

GSMA’s DLT vision document outlines identity of IoT devices and access control as the foundation use case for IoT. We assume that the POC resulting from the present work will act as a foundation work for the rest of their use cases like those related to supply chain, data sharing and integrity.

Design Details

...

The general architecture of the solution will be as follows:

Image Removed

Initially, a smart contract is deployed on Fabric which will be responsible for onboarding and creating trust anchor roles for any new actor. The fabric will be composed of the organizations responsible for taking decision on the actor’s identity creation. These can be members of the board. For  For our POC we will create a network with dummy organizations. Once the initial roles are created, with each step of the supply chain, creation of series of identities will occur. Consider the following steps:

Image Added

1. Device Creation: Once the device is created, the corresponding identity of the device will be created. This will contain the device id (uuid), manufacturing company, status. The claim issuer in this case would be the manufacturing company, the holder will be the device, and the verifier would be the users. We will maintain status as a separate identity as the status will be changing across the process and thus, will require revocation and recreation will be frequent.
2. QA Testing: Once the QA testing is done and the result is available, corresponding identity will be created on the Indy. The claim issuer will be the QA team, the holder will be the device, and the verifier will be the users interested in the status. The QA test result will be the value which will be held in the identity. The previous status will be revoked and a new status will be created.
3. Supplier: Once the device is with supplier, again the status will be revoked and recreated. Other details like supplier details will form another identity. The claim issuer will be the supplier, the holder will be the device, and the verifier will be the users interested in the status.
4. User: The identity other than the status will be the user registration details which will be created. The user will be the issuer, the device will be the holder, and the users will be the verifiers.
5. Recycle: The status and the date will be recorded as a separate identity. The issuer will be the user of the device, the holder will be the device and the verifier will be the user interested in the status.

Network: The sample fabric network will be designed with 4 organizations with 2 peers (though it can be scaled to include more organizations and peers) and will form a consensus among themselves. The smart contract will control the transactions being accepted into the network. The initial setup of the Indy requiring the creation of steward will be done via the contract. The Steward will then create other roles and once setup, the normal operation will resume. The smart contract will be the gateway to the network.

...