Verifiable Credential Management Pallet (VCMP)

The Verifiable Credential Management Pallet (VCMP) enables the creation, management, and verification of verifiable credentials.

Introduction

The VCMP provides a way for users to manage the lifecycle of their verifiable credentials, including creating, issuing, revoking, and updating them. It also enables individuals to store and manage their own verifiable credentials, granting them more control over their personal data and the ability to selectively disclose it to others.

The VCMP interoperates with the Litentry IdentityHub (IDHub) which incorporates features such as secure storage, user authentication, and audit logging to enhance the security and trustworthiness of the credentialing process.

Overall, it is an important component of the identity ecosystem, providing a standardized way for users to create and manage verifiable credentials that can be trusted and verified by others.

Since the VCMP manages VCs, it is important to discuss what VCs are - Verifiable credentials (VCs) are stored as clear text JSON files, which use the JavaScript Object Notation (JSON) format for storing and exchanging data. JSON is a text-based format that uses human-readable text to represent data objects consisting of attribute-value pairs and array data types. It is often used for transmitting data over networks or storing data in NoSQL databases because it is lightweight and easy to read and write.

In a JSON file, data is organized into key-value pairs, with keys represented by strings enclosed in quotation marks and values represented by strings, numbers, booleans, arrays, or other data types. In the case of Litentry VCs, the JSON files are composed of three main parts:

The issuer’s enclave attestation metadata — Verifiable Credentials often include metadata about the issuer, which is the entity that issues the VCs. This metadata is called the issuer’s enclave attestation metadata and it provides information about the security of the issuer’s enclave. An enclave is a secure, isolated environment within a computer or device that is used to protect sensitive information, such as cryptographic keys and private data. The issuer’s enclave attestation metadata includes details about the type of enclave used by the issuer, the security measures and capabilities of the enclave, and any relevant security certifications or attestations. This information allows credential verifiers to assess the security of the issuer’s enclave and determine the trustworthiness of the VCs issued by the issuer. In a verifiable credential system, the issuer’s enclave attestation metadata may be included as part of the VC or stored separately and referenced by the VC. This allows credential verifiers to easily access and verify the metadata when verifying the authenticity of a VC.
The Assertions — Verifiable Credentials often include assertions, which are statements made by the credential issuer about the information contained in the VC. Assertions specify the subject of the credential, the type of information being asserted, and the value of the information being asserted. They are written in a domain Specific Language (DSL) that contains a set of steps to describe how to fetch and calculate data. The DSL is a type of code that can be automatically generated into Parachain runtime codes or TypeScript SDK codes. It enables flexibility, isolation, and standardization of data, as well as improves the verifiability of assertions (data, values, information, etc.) through trustless, automatically generated codes. Assertions have their own execution flow that defines how they are executed based on data that matches the VC registry. They are used to define the standard of the Litentry context based on the data provided by data providers. In other words, assertions help ensure that VCs contain accurate and trustworthy information that can be easily verified.

The signature proof — this is provided by the issuer enclave’s private key and it is a type of digital signature that is used to authenticate the identity of the issuer and the integrity of the issued document. In essence, the signature is a cryptographic function that takes the issuer’s private key and the document’s content as inputs and produces a unique signature as output. This signature can then be verified using the issuer’s public key, which is typically shared with the recipient of the document. This allows the recipient to confirm that the document has not been tampered with and that it was indeed issued by the issuer.

Each of the JSON file components is shown below:

PreviousPallets and Modules NextParts of a VCMP

Last updated 1 year ago

Introduction

Overall, it is an important component of the identity ecosystem, providing a standardized way for users to create and manage verifiable credentials that can be trusted and verified by others.

The issuer’s enclave attestation metadata — Verifiable Credentials often include metadata about the issuer, which is the entity that issues the VCs. This metadata is called the issuer’s enclave attestation metadata and it provides information about the security of the issuer’s enclave. An enclave is a secure, isolated environment within a computer or device that is used to protect sensitive information, such as cryptographic keys and private data. The issuer’s enclave attestation metadata includes details about the type of enclave used by the issuer, the security measures and capabilities of the enclave, and any relevant security certifications or attestations. This information allows credential verifiers to assess the security of the issuer’s enclave and determine the trustworthiness of the VCs issued by the issuer. In a verifiable credential system, the issuer’s enclave attestation metadata may be included as part of the VC or stored separately and referenced by the VC. This allows credential verifiers to easily access and verify the metadata when verifying the authenticity of a VC.

The Assertions — Verifiable Credentials often include assertions, which are statements made by the credential issuer about the information contained in the VC. Assertions specify the subject of the credential, the type of information being asserted, and the value of the information being asserted. They are written in a domain Specific Language (DSL) that contains a set of steps to describe how to fetch and calculate data. The DSL is a type of code that can be automatically generated into Parachain runtime codes or TypeScript SDK codes. It enables flexibility, isolation, and standardization of data, as well as improves the verifiability of assertions (data, values, information, etc.) through trustless, automatically generated codes. Assertions have their own execution flow that defines how they are executed based on data that matches the VC registry. They are used to define the standard of the Litentry context based on the data provided by data providers. In other words, assertions help ensure that VCs contain accurate and trustworthy information that can be easily verified.

The signature proof — this is provided by the issuer enclave’s private key and it is a type of digital signature that is used to authenticate the identity of the issuer and the integrity of the issued document. In essence, the signature is a cryptographic function that takes the issuer’s private key and the document’s content as inputs and produces a unique signature as output. This signature can then be verified using the issuer’s public key, which is typically shared with the recipient of the document. This allows the recipient to confirm that the document has not been tampered with and that it was indeed issued by the issuer.

Each of the JSON file components is shown below: