Components of the IMP

This section explains the different components of the Identity Management Pallet

Since the Identity management pallet directly interacts with the front end, it is made up of different components. These components include:

Identity Struct

An Identity Struct is a JSON data structure that contains information about an individual's identity. This data structure is used to represent and manage the attributes and characteristics of a user’s digital identity within the hub.

The IdentityHub supports linking, unlinking, and verifying multiple identities in batches to reduce the number of needed calls. It also supports linking multiple identities to one litentry account.

In order to achieve this, multiple fields are packed into one single identity struct and multiple identities as an array in the identity field. A typical example of a single identity struct in the pallet is shown below:

{
	"type": "..",
	"address": "..",
	"webtype": "..",
	"metadata": "..",
	"needVerification": "..",
	"web2ValidationData": {
		"link": ".."
	},
	"web3ValidationData": {
		"message": "..",
		"signature": "..",
		"timestamp": ".."
	}
}

Only identity type and address in the fields are required, other fields are optional:

type- Types of identities to be linked, e.g. Twitter, GitHub, discord, substrate, EVM

address- concrete address or handle, e.g. 0x1234, twitterHandle

webtype- web2 or web3

metadata- placeholder for potential metadata, it makes it more extensible as well.

needVerification - By default, the optional fields are false and only used when linking the identities. if the stated identity type and address need verification. When it’s false, the given identity information will still be stored in TEE, but marked as “untrusted/unverified”; when it’s true, a challenge code will be generated and broadcasted as events for further verification.

web2ValidationData- This is only used when verifying web2 identities e.g. the URL link to the public post where an encrypted message is included.

web3ValidationData- This is only used when verifying web3 identities, e.g calling extrinsincs.

ID Graph

An identity Graph is a data structure that represents the relationships between different identities that belong to the same individual. It represents the relationship between a user’s different accounts and can be used to map out a user’s aggregated identity through any of the associated identity data. The IdentityHub aims to provide the tool to generate an identity graph for the use of generating a user's verifiable identity data for both Web2 and Web3 data.

At its core, it is a collection of information that links together all of the different identities that belong to a single individual. This information includes the identity information in the Identity Struct such as identity type, address, web2 and, web3 data, and other identifying information. By linking all of this information together, an Identity Graph provides a comprehensive view of an individual's digital identity.

An identity graph is retrieved from multiple associated identity pairs with verifiable identity verification proofs. An identity pair is a pairing of two web3 addresses or a pairing of a web3 address and a web2 account, it proves the joint ownership of the two associated accounts.

Data structure

An ID graph is composed of a list of the Web3 and Web2 accounts owned by the owner and their corresponding proofs.

Identity pair

Each ID graph is extracted by ID pairs. An ID pair is made of two decentralized verifiable ownership claims. Each ID pair claims the joint ownership of two accounts, it can be a pairing of two web3 addresses or a pairing of a web3 address and a web2 account. Everyone can verify and trust the ID pair.

Merging

An ID pair is the smallest combination of an ID graph. For ID graphs that have a common address, one ID graph will be merged into the other ID graph and keep only one.

Shielding Key

A shielding key is a 256-bit AES-GCM cryptographic key pair that is generated randomly and protected by the user password. Its public key is used by the Litentry TEE worker to encrypt user-sensitive information when passing back the data. It is used to encrypt all the data in the communication between the user and the Litentry Parachain. The shielding key is generated in the user’s local environment and used by the IDHLS to isolate sensitive user data from the IDH server and all other third parties.

Overall, it is an extra layer of security on top of your Substrate private key (Account) used exclusively to encrypt your data for transmission and ensure only you or the Enclaves can decrypt it.

It is important to note that there are two types of shielding keys;

User shielding key - This key is applied to the on-chain data returned by TEE. TEE shielding key- is used in the other direction (user -> TEE) and is publicly visible.