🔒DID SSI

This section covers all of the key information about our Self Sovereign Identity solution and using DIDs.

How it works

Firstly, let's have a look at a high level explanation of what a DID is and how our DID is going to work.

If you would like a full technical overview, please refer to our additional documentation here: Our DID Method Github Documentation Our implementation on Algorand

Conventional identity management systems are based on centralized authorities. These authorities establish a process by which to entitle a user temporary access to a given identifier element. Nevertheless, the true ownership of the identifier remains on the assigner side and, thus, can be removed, revoked, and reassigned if deemed adequate. This creates an intrinsically asymmetric power relationship between the authority entity and the user. Some examples of this kind of identifiers include:

• Domain names

• Email addresses

• Phone numbers

• IP addresses

• User names

Decentralized Identifiers (DIDs) are a user-centric and open alternative to centralized identity management systems. These systems rely on centralized authorities to establish and manage the identity of individuals online. In contrast, DIDs allow anyone to freely register, publish, and update as many identifiers as necessary without requiring a centralized authority for generation and assignment.

The end-user has true ownership of the assigned identifiers, ensuring that no one but the user can remove, revoke, and/or reassign their digital identity. This model allows for a new digital identity that is Private, Permanent, and Portable (3P), giving users secure and reliable access to digital services.

DIDs are not just a new form of digital identity but also a platform for building trust relationships between parties in a decentralized and secure way. They provide a standard way of describing an identity and its associated data, such as public keys, authentication mechanisms, services, and attributes. DIDs give users greater control over their personal information, ensuring that it remains secure and private.

Overall, DIDs provide a private and secure way of managing digital identities, improving privacy and security for individuals and organizations in the online world.

DID Document

You can think of the DID Document as the equivalent to the Username/Email Address in the conventional approach, specifically, it is just an identifier. The DID document only contains the metadata and public keys associated with the DID, such as the authentication mechanisms, services, and attributes. The purpose of the DID document is to provide a standard way of describing the DID and its associated data, but it does not necessarily contain all of the information about the identity represented by the DID.

When a service or application needs to access your personal information, it would use the DID to retrieve the associated data store or database and then retrieve the specific information it needs from there. This allows you to control who has access to your personal information and gives you greater control over your digital identity.

Overall, the DID document is just one component of the overall DID system, and it's used to describe the DID and its associated metadata and public keys. Personal information is typically stored in a separate data store or database that is associated with the DID but is not contained within the DID document itself.

Your Data (DID Payload)

In this context, the DID Payload is the term we will use for your personal information, such as name, date of birth, and other personal attributes about the individual represented by the DID.

As mentioned above, the DID Document itself is just an ID stored on the blockchain, with all other data stored as pointers elsewhere on other systems such as IPFS. These pointers are cryptographically signed in such a way that it can be proven a given DID Document and the associated DID Payload is legitimate.

Some implementations may choose to store the actual personal data, however, we actually have no plans to do this, opting only to store the minimum information needed to verify the specific checks. If we take for example, your date of birth, this may be needed to prove that you are older than 18; once we have verified this using our KYC process, we will ONLY store a cryptographically signed hash of the fact that you are Confirmed as Older than 18 and NOT your actual date of birth.

We believe this is a critical distinction to make and avoids needless emission of personal information. In the future, if our network becomes large enough and trusted in the wider world, you can see how using your Vold DID as proof of age will be possible.

The web of trust will then look something like this:

The company needs to check the user is older than 18 -> Company trusts the Vold verification process, and Vold DIDs -> user shows VOLD DID and associated 18+ attribute to Company-> Company accepts as proof of age.

This is not too far away from the current world, where we all inherently trust that a Passport, for example, is proof of age because in this case, the Government is the centralized Root of Trust.

VOLD Handle

Your VOLD Handle is your unique Identifier within the VOLD ecosystem; this will be one of the data points that is linked to your DID Document via pointers on IPFS. Your VOLD handle will act like your username with the VOLD ecosystem and will never be recycled.

Badges

Badges are additional rewards users can receive for certain accomplishments within their event participation journey.

On launch, there will be a good number of available badges that can't be earned, and we will continue to add new types of badges over time to match the important accomplishments that can be achieved within the VOLD ecosystem. We want these Badges to be a real reminder to each member of the community of the positive action they have taken. Again these will be securely stored off-chain and point to your DID Document.

Credentials/Qualifications

Real world events have unique aspects in the sense that a person's real-world credentials are very important, particularly given that most of the events will involve physical interaction, in potentially hazardous situations.

Because of this, we have a built-in mechanism allowing users to verify and load in their credentials. This is critical for many events that may require medical expertise or involve interactions with vulnerable individuals, whereby certain checks/certifications may be needed.