Moonlight has released an introduction to Vivid, a decentralized self-sovereign identity (SSI) solution and NeoID candidate. Vivid enables the creation and management of digital identities on Neo, and provides the infrastructure for creating on-chain proofs of attribute verification.
Vivid seeks to provide users and businesses with a decentralized platform for managing their digital presence. The solution is designed to be general-purpose and suited for integration into off- and on-chain applications of all kinds, and will be used within Moonlight’s product suite to implement its verification workflows.
Like NeoFS, Vivid is designed to be a public utility, open for integration into dApps on the Neo network. Just as NeoFS provides the opportunity for projects to shift their infrastructure away from centralized data centres, NeoID candidates aim to tackle the trust problems inherent in online interactions, providing safeguards for user data, metrics for information credibility, and tools for achieving regulatory compliance in dApps.
Vivid is also designed with off-chain applications in mind; the blockchain can be used as a back-end for verifying claims without requiring any further interaction on the part of the application. It should be noted that no additional fees are attached to any blockchain interaction with Vivid; only the GAS cost of contract invocation on the Neo blockchain needs to be covered.
Further, since Vivid’s verification workflows are offered as white-label solutions, applications can avoid the development overhead for implementation while providing a seamless UX for their clientbase. In a conversation with Neo News Today, Moonlight co-founder Tyler Adams commented on the significance of this point: “People don’t need to know they are using blockchain to be using blockchain. Most of the users won’t be in our space, but they can still benefit from it.”
Every Vivid user (whether an individual or large-scale entity) begins with the creation of a digital identity. Identities are tied to public keys, and users have the ability to be able to create multiple identities to meet their needs. For example, a user could leverage this feature to create an extra layer of data security by creating a separate identity for each application they access.
Each identity can have one or more on-chain claims, which can be thought of as an alternative to physical credentials such as a passport. Claims are issued by validation providers, and contain a collection of information (attestations) about an identity. These statements could take any form—they could be a simple piece of information such as an individual’s date of birth, membership of an organization, or more abstract, for example whether or not the linked identity owned a specific asset at a particular time.
In addition to the value of a particular attribute, attestations also include a remark, a unique identifier, and can be encrypted in a variety of ways. Keys can be generated by the identity owner that only allow read access to a specific attestation rather than the whole claim, effectively allowing the user to delegate read permissions for some data while keeping other information encrypted.
For an example of this, consider using a passport to prove nationality in order to complete KYC for an exchange. The exchange only needs to verify the user’s nationality, however the whole passport is required so that its credibility can be verified.
Rather than this process, analogous to giving read access to a full claim in Vivid, a key can be generated that only provides access to the information of a particular field, in this case the user’s nationality, while other attestations in the claim remain encrypted. Alternatively, zero-knowledge proofs could also be issued and used for verification purposes.
Assuming the third party is satisfied with the credibility of the claim itself, i.e accepts Moonlight as the claim issuer and root of trust, it can verify the nationality without viewing extraneous personal information. This provides users with granular control over what information they share and with whom, a fundamental goal of self-sovereign identity intended to reduce the potential for data misuse and theft.
Vivid and Moonlight
The usage of Vivid within the Moonlight platform begins during the registration process. After signing up, a unique digital identity is created on-chain for each user. Every identity is accompanied by a root keypair, generated and stored on-chain (the root private key is asymmetrically encrypted).
Moonlight also integrates with Vivid as a validation provider, meaning that it acts as a claim issuer. This is an important role in any digital identity solution, as without validator services there is no origin of truth for any particular piece of information.
For its Copernicus MVP, the team included validation workflows for email addresses alongside GitHub and StackOverflow accounts, however in the future it is intended for new attributes to be supported for verification.
After a user has completed a particular verification process—verifying an email address for example—a claim is issued on-chain containing the attestation for the verified email address. This attestation payload can only be read by entities with a particular key.
Vivid is designed to be unopinionated when it comes to key issuance, remaining flexible to meet the needs of different application types. In the case of Moonlight’s current email verification workflow, two keys are issued; one to the root key of the user, and one to the root key of Moonlight’s public identity. This means that only the user and Moonlight have the ability to check the value stored on the blockchain.
Moonlight recently made its second release candidate available for testing, including a number of UX and performance improvements. According to the team, “odd” releases will be accompanied by new features, while “even” releases will focus on maintenance and incremental enhancement.
Alternate application examples
Digital identity solutions can be used in a wide range of application scenarios. In its simplest form, this could involve using Vivid as a universal login method, using its industry-standard OAuth2 flow as an alternative to the centralized social login solutions offered by entities such as Facebook and Google.
Additionally, entities could also register as validators with the Claims contract, allowing them to issue credentials for use in their own or other applications. Putting claims on the blockchain allows them to leverage the benefits of immutability, preserving information that could otherwise be lost or withheld.
As an example, consider a student that needs to verify a degree in order to land a job. Typically this process would involve going through one or more third parties, such as the National Student Clearinghouse, costing a fee and with no guarantee of a desired result. If a degree was issued as a claim on-chain, the record would persist even if the issuing body ceased to exist or the request for third-party verification was otherwise refused.
That being said, businesses do not need to offer their own attribute validation or integrate Vivid as a login service in order to benefit from the solution. As all claims, keys, and verification events are stored on-chain, vendors can tap into the solution to verify users based on existing claims (assuming the user chooses to share such information with the vendor).
For example, a social network seeking to reduce election tampering via astroturfing could use existing citizenship verification (provided by a validator such as Moonlight) in order to restrict the right to post or label the posts of verified citizens.
The full Vivid product announcement can be found at the below link: