♻️The 3-Sided Marketplace of Verifiable Data

Issuer > Holder > Verifier

Let's take a look at an example.

Degen University is the Issuer and issues a diploma in the form of a Verifiable Credential (VC) to Alex as the Recipient for their graduation on a specific date. They use Disco to accept the credential and apply for a job. The employer, acting as a Verifier, who will verify the credential via Disco's API endpoints.

In this scenario, the inherent trust model comes into play in three ways:

1. Alex can prove who issued the credential, as Degen University's DID is unique to them.

2. Alex owns the credential and is the subject of the claim (i.e. their Degree in Arts).

3. The credential is valid, and the cryptography has not been tampered with.

Parties Involved 🥂

🏛️ Issuer

Whoever is issuing a claim, or credential. This could be any governing body, entity, university, or organization! They’ll sign the claim with their public and private key-pairs so it’s legit.

🎒 Recipient

Whoever is receiving a claim, or credential. They will ultimately own these credentials and control how it’s shared. They’ll have a DID so it’ll be unique to that address only.

🏫 Verifier

An entity that verifies if the credential is authentic and valid. Typically, they’ll ensure that it is legitimate, tamper-proof, and is still relevant on the requested date.