...
To create an identity system for IoT devices and involved actors, thereby, laying the foundation for application to various IoT use cases. In particular, we focus on the identity access, identity association with id, monitor the supply chain. Further extending the system potentially in the future to enable device-to-device interaction enabling autonomous service exposure and consumption.
...
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:
...
From the use case:
Device status is a particularly important attribute of the device because this is very difficult to trust at present especially when buying from less official channels. Device status can contain multiple attributes and permissions to add/ update attributes may differ according to the user role e.g.
○ only a manufacturer can allocate a serial number,
○ only the manufacturer QA team can mark a device as having passed QA,
○ only the manufacturer can change the ownership of the device to a
distributor,
○ only a distributor can only a Mobile Network Operator can allocate an MSISDN;
Detail Steps:
- Schema Creation, Credential Definition Creation.
- Distributor (Mobile Network Operator) with create schema (Telecom Schema) as standard in the entire supply chain. Both Producer (Manufacturer, called pineapple in our demo) and QA team ( is the QA team of the Manufacturer) will together create Credential Definition.
- To simplify the reality, in the use case, the Manufacturer is a different entity compare to MNO (although could be the same some times). Also usually you have several distributors in this case GSMA, assumed only one to make it easier.
- Device Creation
- Once the device is created, the corresponding identity (DID Documents) of the device will be created. The device will be treated as an independent thing and receive the credential from Producer. The device shall shall be assigned the series number from manufacturer.
- QA Testing
- The device will be passed through QA testing. In the demo, assume passing the QA.
- After QA pass, manufacturer will offer a Credential Offer for the device. The device shall receive the Credential from manufacturer. (currently, our credential including: manufacturer, sequence_id, bandwidth, QA_status, history = null)
- Passing device through Distributor
- After receiving Credential from Producer and QA Team, the Distributor (Mobile Network Operator) will assigned and MSISDN in DID Documents of device. After that, the device can connect to the internet.
We simply use the DID to mark the ownership and access control. The KYC process and recycling process are not taken into consideration currently. The changing of ownership from manufacturer to operator, and from operator to end user is use the revoke of DID and claim new DID.
Network: The network will be designed with 4 organizations with 2 peers (though it can be scaled to include more organizations and peers3 organizations (Distributor, Producer, QA Team) with 3 peers (User, device A, device B) and will form a consensus among themselves. The smart contract DID documents and Verkeys 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.Smart Contract: The smart contract is a replacement for a trusted entity since the code will be shared with the participating entities and will be deployed by consensus. The contract is responsible for creation of Steward role. Usually, Stewards are important members of a governing body.
DID and Verkey: DIDs work as the role of trust anchor to the ledger, as we create Steward’s DID. The actions (including owner’s action and manufacturer's action) is written on the ledger, generate new DID/Verkey pairs. After that, Prover uses Credential Offer to create Credential Request. Trust Anchor then uses Prover's Credential Request to issue a Credential. Steward is then responsible of creating other actors like manufacturer (production line), manufacturer ( QA )team, wholesaler, distributor (mobile operator) and end customer at various stages. For all the actors, the Steward will onboarding actors mentioned above and then grant verinym and a trust anchor role. .
Implementation
https://github.com/quantumcatwang/Telecom-IoT-device-SSI