Toolkit functionality

Status: in development

Getting started

The vSelf verifiable credential toolkit provides a user-friendly interface to issue, hold, sign, and verify all the types of VCs described here in our web applications. We address Web2 users and build our application with a well-understandable design to facilitate mass adoption.

Create the credential shame

Our toolkit contains the easy-to-use constructor for the credentials. The issuer is able to choose which type of verifiable credential she wants to set up. vSelf provides the questionnaire inside the web to detect the issuer's needs and preferences. We propose to the issuer the most suitable type of credential and its description according to her answers. It helps the issuer to understand the properties of each credential type and make the right choice. The token type field contains appropriate information to process and view the credential on the vSelf application.

After the credential type is chosen, the issuer should construct the credential shame. This shame constructs using the web form in the vSelf application. It includes all the fields with the mark "set by the issuer" in the credential data structure. The issuer should fill in all the fields necessary to define, can fill in additional ones, and also is able to upload the source file in this form. If the source file is provided, we store it in Filecoin and add the appropriate link to the credential shame. vSelf calculates other credential metadata with the mark "set by vSelf" according to the data provided by the issuer. Then the credential shame is expected to be ready. The issuer is able to save or delete this credential shame. We store this shames on the issuer side in GunDB, offline-first & distributed graph database. All the shames created by the issuer are available in her vSelf personal area on the "credential shames" page.

Issue the credential

The issuer is able to choose the ready credential shame and appropriate mint credentials for the holder. In the case of the public credential, all the data provided in the credential shame is retrieved in the transaction without any changes. We store the issued credential ids in the GunDB.

If the credential is private, the issuer should provide the implicit holder's NEAR id. This id is expected to be provided by the holder to the issuer directly. Before minting the credential, we use ECC algorithm to encrypt all the metadata expect the issuer and holder ids using the holder's public key (token holder id in the credential shame) and replace the token holder id value with the implicit holder's NEAR id in the credential metadata. We also save the original holder's NEAR id with the token id to the GunDB. It is necessary for the issuer to parse this credential metadata correctly in the future.

After that, the minted credential appears in the issuer personal area in the "minted credentials" page. The issuer can manage (revoke or update) any of the minted credential.

Receive the credential

We integrate The Graph Protocol and use the NEAR subgraph to search and index all the credentials efficiently. We automatically retrieve all the credentials according authorized NEAR id in the user vSelf personal area in the "received credentials" page.

View the credential

There are several pages with the lists of the credentials in the vSelf personal area:

• Minted: The issuer is able to see all the credentials she has minted;

• Received: All the vSelf credentials available for the current NEAR wallet;

• Request: The credentials with the request type: signature, verification, or use request.

In the vSelf personal area, the user can sort her verifiable credentials and choose which ones she wants to disclose in her sub-identities.

The credential can be shown in the vSelf application with the custom illustrated file or with the default one. To show a custom illustrated file, all of these points should be true:

• The credential metadata should contain a source file hash link

• This hash link should be valid (the source file is available & its hash equals saved hash)

• The illustrated file format is supported in the vSelf platform

If anything from this list isn't true, the illustrated file in changed to the default one with the appropriate message.

In case of the private credentials there is the additional step - to decrypt all the metadata using appropriate key. It is expected that multi-wallet user profile is already available. For this reason we can retrieve credentials using The Graph Protocol NEAR subgraph for all the connected NEAR wallets. The received private credential should be uploaded through this subgraph. The public key to decrypt the credential data can be chosen from the list of the connected NEAR ids.

Issue the multi-signature credential & the signature request

After the multi-signature credential is minted, the signature request tokens are minted for all the authorities. These tokens are recognized as an appropriate request and appear in the authorities personal areas in request pages. The signature request token matches the original credential, and authority can find and refresh the credential metadata by adding her signature for the appropriate field. The request signature token can be burned.

In case of the private original credential there is the additional step - to use the decrypted metadata of the original credential on the issuer side and to encrypt all the request token metadata using authority public key.

The usable credential & the use request

After the use credential is minted, the holder is able to exchange this credential for some benefit. For this goal the holder mints the use request token for one curators from the curators list. This token is recognized as an appropriate request and appears in the curator personal area in request pages. The use request token matches the original credential, and curator can find and refresh the credential metadata by changing the token use status. After that, the curator must provide the benefit to the holder. The request use token can be burned.

In case of the private original credential there is the additional step - to use the decrypted metadata of the original credential on the holder side and to encrypt all the request token metadata using curator public key.

The proofed credential & the validation request

In this section we discuss the validation request tokens for two cases: the fixed-validator proofed credential and the community-validator proofed credential.

The proofed credential allows the holder to mint the validation request tokens for the appropriate validators. The appropriate validator is the validator from the validator list in the credential metadata for the first case, and any holder of the proofed community membership badge in the second one.

All the validation request tokens appear in the validator personal areas in the request pages. The validation request token matches the original credential, and validator can find this credential. The validator is able to check the credential, make the decision about it's validation, and refresh the credential metadata by adding her name, decision and signature for the appropriate fields. The validation request token can be burned.

In case of the private original credential there is the additional step - to use the decrypted metadata of the original credential on the holder side and to encrypt all the request token metadata using verifier public key.

Verify the credential

The option to verify any credential is available for users in their private area in the "verify credential" page. We implement The Graph Protocol and use the NEAR subgraph to search credentials by their token id. In this case user is able to provide any credential id and find it in the vSelf application. The verification process is provided automatically after the credential is found. The verification process consists of checking:

• token revoke status (token revoke status should be false)

• Credential ownership (the credential owner should match the credential holder)

• Hash link of the source file (the link to the source file should be valid, and the hash of the source file should match the saved hash)

• Issuance & estimated date (the current timestamp should be more than the issuance date and less then the estimated date)

• token signature status (for the multi-signature credentials, all the authority signatures should present)

• token use status (for the use credentials, token use status should be false)

• token verification status (for the proofed credentials, all the verifier positive solutions & signatures according token verification mode should present)

If all of these conditions are met, the given credential is expected to be valid. The verification isn't supported for the private credentials.

Verifiable presentation

The user is able to create verifiable presentation from several received credentials. The holder of the credentials is able to construct verifiable presentation shame and mint appropriate self-issued credential using this shame.

To do this, the holder should choose several verifiable credentials and choose which metadata from the each credential will be presented in verifiable presentation. Both public and private credentials are available to add in the verifiable presentation. In case of private credential, the holder has an access to the original decrypted metadata. This metadata is retrieved to the presentation.

The verifiable presentation is useful to share the data from private credential with the third parties. And also this mechanics allows user to create here CV in the single token.