Litentry is a second layer protocol and infrastructure based on Substrate. It focuses on Identity of person and IoT devices, and the authorization and permissions granted by the Person or IoT devices.
It mainly includes three parts:
1. Identity runtime module
2. API server
3. Identity management application
Identity runtime module
The identity runtime protocol abstract all the persons and devices authorization scenario, includes three basic definitions:
Identity Registry: a pre-defined key pair to present a person or a device.
Token: a non-fungible token issued by the identity.
Data: the related identity data, like identity meta information and token specification.
Person ID chain:
Identity Registry: crypto key pairs bind to national identity number;
Token: a token created by the person, which could be used to validate the age;
Data: the data of the person, e.g. birth date and place, gender, etc.
Locks Registry: crypto key pairs bind to the smart IoT lock;
Token: a token created by the lock, which could be used as an entry key.
Data: the definition of the token, e.g how many times could one token be used.
Cross Chain Validation
Such a protocol could be easily combined for the Polkadot cross chain feature, thus could realize many new ideas:
For example, the entry token on the lock chain need to be combined together with the personal ID chain, the entry token is only valid if the user's age is more than 18. The other personal data will not be exposed at the same time.
Runtime Specific Data Operation:
An IoT device manufacturer could have its own data operation functions, for example, it may harvest the data from all the temperature sensors and pay DOT to the sensor owners.
The large data bind to the identity owner, i.e. person or devices, will be saved into an IPFS data server, the entry hash link will bind to their identity. The benefit of it is once the data updates, the old link will be also disabled. In order to always get the available data, others need to ask permission from the user.
The middle layer connects the runtime module and frontend applications for users.
Event listener and off-chain caching server: With cached data it reduces the query load on the blockchain, furthermore, it saves the caching data on the centralized database in order to improve the speed of application-based blockchain query, like Infura for Ethereum. A relay script server is also built here, to automatically trigger an event on periodically regarding block generation.
IPFS caching server: especially for the large data from IPFS, the server will caching the data to the server.
GraphQL validation and query server: validate the authorization tokens with HTTPS request for IoT devices or application.
Personal users would like to use an application to manage all its identities, it could also become a Hub connected to different interest IoT devices. For example, directly buying the authorization or the data from other IoT devices. With the advantage of GPS of mobile phone, it could further integrate with LBS (Location Based Services).
In order to work in a fully decentralized scenario, itself also need to integrate a cold wallet, where could keep a user's private key in a secure environment provided by Android or iOS.
Here are the sketches of the application.
As a device manager with lots of tokens published, it is better to control all the permissions and authorizations through a web app. Thus we are also planning to develop a web app based on React, which will give the user more possibilities to control the identities.