## Introduction

With this proposal, we want to introduce a registrar service that focuses on automatic verifications, leveraging well-designed cryptographical challenges to further reduce human interventions. 

In this document, we also share the implementation details and screenshots of key verification steps to offer readers a better understanding of how the respective verification workflow operates.


## Implementation Details

The key components of the Litentry registrar are shown as follows. It mainly includes **Validators**, **Event Listener**, **ProvideJudgement** Service and **Database** Service. Figure1.1 presents the architecture of the Litentry registrar, and Figure1.2 shows the main workflow of the registrar.

The *Event Listener* listens to all events coming from the Kusama chain. Once a *JudgementRequested* event is triggered on Kusama and the *JudgementRequested* indicates to use the Litentry registrar, the *Event Listener* service will invoke *Validators* starting the verification process. 

At the current stage, the *Validators* consist of three verification services, **Email**, **Element**, and **Twitter** verification. After receiving the verification request from the *Event Listener*, the Validator will invoke those verification jobs. They will send a verification link to the users provided accounts and wait for user confirmation from their accounts. As soon as the user confirms all verification links, the ProvideJudgement service will complete the final step, providing judgement for the user. The implementation details will be introduced in the next section separately.

Once the user proves the ownership of the **Email**, **Element,** and **Twitter** account, the *ProvedeJudgement* service will send a JudgementGiven transaction on the Kusama to confirm the ownership of the accounts that the user provides.

The *Database* service will temporarily store users’ data, e.g. Kusama account, **Email**, **Element**, and **Twitter** account, so that we can recover services from an unpredictable crash. After completing the verification service, those data will be removed from the server permanently.


![](https://drive.google.com/uc?id=1jfbLKJxzuv_0sbLdlFadz0mmFHLbvlWn)
Figure 1.1 The Architecture of the Litentry Registrar


## Security and Availability

We use JSON Web Token (JWT) to construct the verification protocol. A nonce and an *ObjectID* (comes from mongodb) are used to generate the JWT token to ensure security of the Litentry registrar. In this implementation, only the user who requests identity judgement, which implies his/her ownership of this Kusama account, will receive this encrypted token. Malicious users cannot construct this token because of an unknown encryption secret, since nonce and ObjectID  are encrypted. And the malicious user has no way to re-play the attacks. 

On the other hand, the websocket (TCP connection) can be easily reset by the remote peer due to long-time idle. In this situation, the events from the Kusama would be never captured since the disconnection between them. To prevent this situation, we capture the events from the underlying websocket connection and reconnect to the Kusama automatically whenever it’s reset by the peer.

#### Email Verification

In the email verification process, we use SendGrid to offer the email service. The JWT token is sent to the user through SendGrid. After that, a verification function is invoked on the server-side to check the JWT token's integrity. As soon as the verification link is confirmed, the status of email verification is set to *“verified”*.


#### Element verification

Compared with the email verification, the Element verification needs one more step. We firstly send an invitation to the user-provided Element account on Kusama data. Once the user accepts the invitation, a JWT token is generated and sent to the user's Element account. As soon as the verification link is confirmed, a verification success message is sent to the user and the status of Element verification is set to “verified”.


#### Twitter verification

In the Twitter verification process, users need to follow the Litentry official registrar account, namely Litentry Registrar (@LitentryReg). Users could also set their accounts to receive any private conversation in their privacy settings. Otherwise, they cannot receive the message from the Litentry registrar. The Twitter verification job then generates the JWT token and sends it to the user's Twitter account. As soon as the verification link is confirmed, a verification success message is sent to the user.  And the status of Twitter verification is set to “verified”.

![](https://drive.google.com/uc?id=1sObhcLRGLCzkg75F5Aao2SuZHLXzHj76)
Figure 1.2  The main Workflow of Verification process

After all fields provided by the user are verified, the *provideJudgement* service will send a transaction to provide the respective judgement for the user.


## User Interaction Highlight

### Email Verification

Users will receive an email called **"Litentry Verification Service"**. Figure 2.1 is an example of email verification. Users only need to click the button "Verify Email Now" to complete proof of email address. Then they will receive another confirmation email that shows the email has been verified successfully.

![](https://drive.google.com/uc?id=1gQmZEoSvYtYb7OxE1yBWA4Vus4Z7UoZO)
Figure 2.1 Email Verification Example



### Element Verification

As for Element, an invitation will be sent from the bot named **"litentry-bot"**. Once the user accepts the invitation, "litentry-bot" will send a verification link. Users only need to click the link to complete verification of the element account. When it proves the user is the account owner, they will receive a confirmation message such as "Verified successfully" (see the figure below).

![](https://drive.google.com/uc?id=12vlbEviR60c2yYrmAYLLixNOpIAUXx-7)
Figure 2.2 Element Verification Example



### Twitter Verification

“Litentry Registrar“ will send a direct message associated with a verification link to the user if he/she follows the Twitter account “@LitentryReg”.  Once the verification link is clicked, 
the verification of Twitter is completed, and you should receive a successful verification message. The following figure is an example of the Twitter account verification process.

![](https://drive.google.com/uc?id=1Wtezykq7RLzYmM5Ep8Cn1H7RgegEev66)
Figure 2.3 Twitter Verification Example



## Conclusion
We strongly believe that with this Registrar service being part of the Kusama ecosystem, it can offer users with a more streamlined verification process at a reduced cost while improving the transparency and usability for providing judgement.



 Add a registrar to the system.

 The dispatch origin for this call must be `T::RegistrarOrigin`.

 - `account`: the account of the registrar.

 Emits `RegistrarAdded` if successful.

 # <weight>
 - `O(R)` where `R` registrar-count (governance-bounded and code-bounded).
 - One storage mutation (codec `O(R)`).
 - One event.
 # </weight>

- This proposal is about introducing a registrar service for automatic verifications.
- The registrar has different components like Validators, Event Listener, ProvideJudgement Service, and Database Service.
- The registrar uses encryption and security measures to protect user information.
- There are different verification processes for email, Element, and Twitter accounts.
- Users receive verification emails or messages and need to click on links to complete the verification process.

#104 A registrar service on Kusama focusing on automatic verifications