Verifiable Credential II: Trustless Workflow in Litentry

This treatise is a sequel to Data Stardust and Constellations, the first part of our series on Verifiable Credentials (VC). This exposition delves deeper into the concept of verifiable credentials and explains its core features, VC and trustless workflow in Litentry, and its generic use cases.

Trustless Workflow in Litentry

Litentry Protocol has introduced a trustless process for Verifiable Credentials (VC) in the Web3 industry, making it the first of its kind. This process includes automated VC generation, issuance, and verification using components that are focused on the Litentry protocol.

The use of digital signatures and public key infrastructure (PKI) allows the issuer and verifier to verify the authenticity and integrity of the credential without having to trust each other. This allows for the issuer to issue a credential to a holder and the holder to present it to a verifier, without either party needing to trust the other. In the Litentry protocol, the trustless workflow process for VCs involves VC entities (author and user) sending information to the Litentry Protocol (ID Hub), which then stores the data in a Data/Storage system (Parachain onchain storage, data providers).

In other words, for Litentry’s workflow: VC entities (author and user) — → Litentry Protocol (ID Hub) — → Data/Storage (Parachain onchain storage, data providers).

VC Schema

To create or generate a VC, it is necessary to have a corresponding VC schema. A VC schema is a data model that defines the information that can be included in a VC and the rules for structuring, formatting, and organizing that information. It typically contains three critical fields: author, id, and content.

In a trustless ecosystem, a VC schema outlines the types of information that can be included in a VC, the relationships between different data elements, and any requirements that must be fulfilled to validate a VC. Anyone can draft and publish a schema to the SchemaRegistry on the parachain. A shared VC schema ensures that all parties can reference documents in a consistent manner, and the schema typically adheres to existing data standards, such as the W3C Verifiable Credentials Data Model.

Trust Levels of a VC

The trust level of a Verifiable Credential refers to the degree to which a credential verifier can trust the information contained in the credential. The trust level of a VC may be determined by various factors, such as the identity of the credential issuer, the level of scrutiny applied to the issuance process, and the security measures in place to protect the credential from tampering or fraud.

Verifiable Credentials (VC) can have different levels of trust, ranging from low to medium and high. A low-trust VC is one that has been issued by an unknown or untrusted issuer or has undergone an inadequate issuance process. Such VCs are less likely to be accepted by credential verifiers. A medium trust VC is one that has been issued by a reputable issuer and has undergone some level of verification or scrutiny during the issuance process. It is more widely accepted by verifiers, but may still require additional verification.

In contrast, a VC with a high level of trust, such as those issued by the Litentry Protocol, has been issued by a highly reputable and trusted issuer and has undergone a thorough and rigorous verification process. The Litentry Protocol achieves this high level of trust through various mechanisms, including open source codes, TEE, Trusted data providers, VC registry (IDHub), assertions, digital signatures, proof, and issuer. These mechanisms cover different user scenarios and work together to ensure the core features of a verifiable credential, including privacy protection, minimal disclosure, decentralization, trustlessness, portability, and transparency.

A VC with a high trust level is widely accepted by verifiers and may be considered equivalent to a traditional form of identification or proof of qualification.

Verifiable Credentials in Litentry Protocol — Identity Hub

On a general note, the IDHub is an onchain VC registry, which means that it is a secure storage system for VCs and it operates on the Litentry Parachain. Storing VCs on the parachain provides a secure and tamper-evident record of the credentials. This allows individuals, DApps, and organizations to securely store and manage their verifiable credentials, and make them available to others who need to verify their identity or other attributes.

Parachain verifiable credentials registries are more efficient and scalable than traditional onchain verifiable credentials registries, as they can take advantage of the specialized nature of the parachain to optimize their operations. (Parachain shares the security mechanism of the underlying Polkadot Relaychain and is connected to many other parachains. Read more about this here.)

The extrinsic to query the validity of VC from Parachain onchain storage are initially populated when the VC is issued. Litentry Parachain maintains onchain storage with a pair <VC DID, {trx_hash, status}>, and provides an external extrinsic for the verifier to query and validate the VC status.

Using VCs

The following are the core features of a VC that works together to facilitate trust between the entities:

• Issuer: An issuer is an entity that issues the credential to a recipient. VCs can be issued by anyone, though usually by a trusted entity such as a Web3 project or organization. This entity is responsible for verifying the information included in the credential and for digitally signing the credential to attest to its authenticity. The issuer’s digital signature, which is created using the issuer’s private key, can then be verified by the recipient using the issuer’s public key. This allows the recipient to confirm that the credential has not been tampered with and that it was indeed issued by the trusted issuer. In the context of Litentry protocol, the issuer is the Litentry TEE Worker which allows information to be synchronized and computed.
• Verifier: A verifier is an entity that ascertains the authenticity and validity of the credential. The verifier can use the credential’s digital signature, which was created by the issuer using the issuer’s private key, to confirm the authenticity of the credential. The verifier can also use the issuer’s public key, which is typically shared with him, to verify the credential’s digital signature and ensure that it has not been tampered with. The verifier can verify the information included in the credential against the issuer’s rules and regulations to confirm that the credential is valid. This allows the verifier to make an informed decision about whether to accept the credential as evidence of the recipient’s identity or qualifications. With Litentry protocol, the verifier is usually a DApp and it verifies credentials about a given subject.
• Holder: The holder is the ID-Hub user. It is usually, but not always, the subject of VC. The ID-Hub user possesses the credential and can use it to prove their identity or qualifications to a verifier. It is the owner of the credential and has the right to use it as evidence of its identity or qualifications. The holder also has the ability to share the credential with others, such as when presenting it to a verifier for verification.
• Registry: Litentry Identity Hub is the VC registry. It is the decentralized system that is responsible for maintaining a list or directory of issued credentials. The registry typically includes information about the issuer, the credential’s subject (the individual to whom the credential was issued), and the credential’s status (active, revoked, expired, etc.). This information can be accessed by verifiers to verify the authenticity and validity of a credential presented by a holder. The registry can also provide additional services, such as allowing holders to manage their credentials or enabling issuers to publish and share information about their credentials.

Summarily, the cycle of the sequence of events in a verifiable credential ecosystem is as follows:

1. Issue. The first event in the sequence is the issuance of a VC. This involves an issuer issuing a verifiable credential to a holder.
2. Transfer. Once received by the holder, the holder may transfer one or more of its VC to another holder or may optionally present its VC(s) to a verifier.
3. Verify. The verifier determines the authenticity of the VC and this includes a status check for revocation of the verifiable credential.
4. An issuer might then decide to revoke a verifiable credential; or
5. A holder might delete a verifiable credential.

Although the order of the actions above is not always fixed, the most common sequence of action is usually:

• An issuer issues to a holder
• The holder presents to a verifier
• The verifier verifies.

Components of a VC

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:

1. 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.
2. 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.

3. 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 these JSON file components is shown below:

Generic Use Cases

Verifiable Credentials can be used in a variety of different scenarios and for a range of different purposes depending on the specific needs and requirements of the parties involved. Some potential use cases for decentralized VCs include:

• Identity verification: VCs can be used to verify the identity of an individual, or organization, allowing them to access services or resources that require proof of identity. For example, an agency could issue a VC to an individual that contains their name, date of birth, and a digital signature from the agency, which the individual could then present to a third party to verify their identity.
• Access control: VCs can be used to grant or restrict access to digital resources. For example, an individual could issue a VC to an entity that grants them access to all or part of a resource, and the individual could present that VC to gain access.
• Voting power / Governance: VCs can be issued to grant governance or voting power to individuals such that it establishes their reputation and give them access to the voting module from which they can exercise their democratic right.
• Proof of ownership: VCs can be used to securely and verifiably establish ownership of an asset, allowing the owner to transfer ownership or access rights to the asset.
• Loan — a credit VC can be issued to verify the identity of the borrower, as well as to provide proof of income, creditworthiness, and other factors that are relevant to the loan application process. This then gives the verifier the basis to decide if to approve or reject the loan application.
• Supply chain tracking — VCs can be used to track and verify the provenance and authenticity of products in a supply chain. For example, a manufacturer could issue a VC to a product that contains information about its origin, production date, and quality control measures, which the product could then pass along to each subsequent party in the supply chain (such as a distributor, retailer, or consumer) to verify its authenticity and provenance.

Conclusion

Verifiable credential (VC) is a concept that enables individuals to hold and share their digital identities with ease, privacy, and security. It is based on the idea that identity attributes can be cryptographically signed and verified by trusted parties. The core features of VC include privacy protection, selective disclosure, and interoperability.

Litentry pioneered the design of a trustless workflow of VC in the web3 space. This trustless workflow involves decentralized identifier (DID) creation, VC issuance and presentation, and verification by using Litentry protocol-focused components.

The generic use cases of VC are extensive, including KYC/AML compliance, access control, data authorization, supply chain tracking, and more.

Special thanks to shoutout to Mel and the Litentry design team for their invaluable contribution to this article.