GITBOOK-159: change request with no subject merged in GitBook

SUMMARY.md

@@ -36,8 +36,8 @@
   * [Network Parameters](cheq/tokenomics/parameters.md)
 * [✍️ Identity writes](cheq/identity-writes.md)
 * [♻️ Credential Payments](cheq/credential-payments/README.md)
+  * [Verifier pays Issuer](cheq/credential-payments/verifier-pays-issuer.md)
   * [Holder pays Issuer](cheq/credential-payments/cheqd-use-case-examples.md)
-  * [Verifier pays issuer](cheq/credential-payments/verifier-pays-issuer.md)
 
 ## Governance
 

cheq/credential-payments/README.md

@@ -2,35 +2,24 @@
 description: Understand how $CHEQ is used for payments for verifiable credentials
 ---
 
-# ♻ Credential Payments
+# ♻️ Credential Payments
 
-## Payment models explained
+## Overview
 
 One of the most repeated bits of feedback that we've had, throughout our survey results and community engagement, is that: **more easy explanation and examples on how cheqd can be used in practice would better help people understand the project**.
 
-This page will try and lay out simple use cases where cheqd will be able to create new commercial models. It will be split into two parts:
-
-1. What cheqd fixes now
-2. What cheqd fixes in Web 3.0
-
-### Holder pays issuer
-
-A holder could pay for Verifiable Credentials from an issuer. An instance where this could be useful is an individual paying for their education records or employment records, to be able to have a stronger CV.
+These subpages will try and lay out simple use cases where cheqd will be able to create new commercial models.
 
-![Holder pays Issuer](<../../.gitbook/assets/Holder pays Issuer.png>)
+<table data-card-size="large" data-view="cards"><thead><tr><th></th><th></th><th data-hidden data-card-target data-type="content-ref"></th></tr></thead><tbody><tr><td><mark style="color:blue;"><strong>Verifier Pays Issuer</strong></mark></td><td>This is cheqd's unique superpower for monetising credential issuance, creating new commercial models for companies engaging in credential ecosystems.</td><td><a href="verifier-pays-issuer.md">verifier-pays-issuer.md</a></td></tr><tr><td><mark style="color:blue;"><strong>Holder pays Issuer</strong></mark></td><td>A more simple payment flow, enabling Holders to pay Issuers directly for "purchasing" credentials from them.</td><td><a href="cheqd-use-case-examples.md">cheqd-use-case-examples.md</a></td></tr></tbody></table>
 
-### Verifier pays holder
-
-A verifier could pay a holder for sharing Verifiable Credentials. This may be an important use case where a company wants to receive extra preference data from a holder, and is willing to pay a fee for it because it is verifiable.
-
-![Verifier pays Holder](<../../.gitbook/assets/Verifier pays Holder.png>)
+## Payment models explained
 
-### Verifier pays issuer
+There has been a **consistent cold start problem for digital credential ecosystems** where organisations do not see a clear commercial model or revenue opportunity to justify the switch up costs to credential-based technologies. This is because the perceived value in Verifiable Credentials is the costs saved when there is a significant amount in circulation (the chicken🐔), but this cannot occur without organisations issuing credentials in the first place (the egg🥚).
 
-A verifier could pay the issuer for Verifiable Credentials it receives from the holder. This gives the issuer a recurring revenue stream each time the Credentials it issues need to be live-checked by the issuer.
+Unfortunately, the benefits of credentials, prior to the point of mass adoption, provide no compelling reason for businesses to change their current data collection and retention practices until this is the case.
 
-The mechanism for this payment is through a revocation registry that the issuer establishes. The verifier will make a payment only if it wants to check whether the holder’s credentials have been revoked or not.
+Since launching cheqd, our hypothesis has been that **Credential Payments will be the catalyst for credential adoption**, by incentivising issuers to release data back to the holder, and allowing them to set a price for trusted data checks. This thinking has since been validated by data collected by cheqd’s partners and potential customers, where **70% of respondents believed that payment rails would help drive adoption with their customers.**
 
-This is important to maintain privacy of the holder, preventing a correlation risk.
+We now believe that credential ecosystems are technically mature enough to scale, especially with [new regulations like eIDAS 2.0](https://blog.avast.com/eidas-2.0-avast) accelerating their adoption and providing a template for interoperability. Yet, there is a barrier between the theoretical and philosophical benefits of Verifiable Credentials, and the commercial and business benefits of Verifiable Credentials. A **payments or incentive layer is still required to provide a compelling reason for **_**enterprise organisations**_** to make the switch**.
 
-![Verifier pays Issuer](<../../.gitbook/assets/Verifier pays Issuer.png>)
+To achieve this shift, we’ve built Credential Payments into our [**cheqd Studio**](https://cheqd.io/solutions/cheqd-studio/) product to allow organisations to build trusted data markets easily, with simple REST APIs. This abstracts the complexity and responsibility of handling interactions with the ledger and provides a clear integration pathway for developers that are not familiar with decentralised identity standards or blockchain.

cheq/credential-payments/verifier-pays-issuer.md

@@ -1,3 +1,64 @@
-# Verifier pays issuer
+---
+description: cheqd's unique superpower for monetising credential issuance
+---
 
-\<todo>
+# Verifier pays Issuer
+
+Verifier pays Issuer is a Credential Payment flow that enables "issuers" to charge a premium fee to validate the legitimacy of the credential's status. This is **an incredibly powerful tool** for companies that want to issue Verifiable Credentials, but also want to put a sensible commercial model in place.
+
+## Example of Verifier pays Issuer flow
+
+![Jane Doe](<../../.gitbook/assets/Jane Doe image.webp>) **This is Jane Doe**
+
+Jane Doe has recently completed her university degree at Bright University. She wants to receive a digital, verifiable and certifiable copy of her diploma to apply for a prospective job.
+
+#### DID and DID-Linked Resource Creation
+
+In order for this to happen, first Bright University needs to register their [**Decentralised Identifier (DID)**](../../decentralised-identity/dids/what-is-a-did.md) to a [Verifiable Data Registry](../../decentralised-identity/dids/what-is-a-vdr.md) or ledger. In this case, Bright University anchor their DID to cheqd, using the cheqd DID method.
+
+Bright University, however, want to make sure that they also receive a payment when Jane uses her digital diploma for other purposes. As such, Bright University create a "Premium" credential with a $20.00 fee to fully validate.
+
+<figure><img src="../../.gitbook/assets/Registering Premium Credential.png" alt=""><figcaption><p>Bright University register DID and chargeable DID-Linked Resource</p></figcaption></figure>
+
+Bright University anchor their DID to cheqd, and create a "chargeable" $20.00 DID-Linked Resource to allow relying parties to Pay to Trust the credential's status and also the governance framework under which the university operates.
+
+The specific Public DID is registered as `did:cheqd:mainnet:923u592u5ghgu3r8` and the DID-Linked Resouce is available via `did:cheqd:mainnet:923u592u5ghgu3r8/resources/5c2529b0-656d-4244-8e55-906d124df523`.
+
+Bright University specify that **$20.00** must be paid to Bright University to access the status information regarding the credential they will issue to Jane.
+
+#### Credential Issuance
+
+Jane has completed her degree and she has successfully achieved a First Class Honours. Now, she wants to receive a digital copy of the diploma to be able to hold it in her digital identity wallet.
+
+On the physical certificate there is a QR code which Jane scans. This creates a peer-to-peer encrypted channel between the University and Jane's phone, which has her digital identity wallet.
+
+Bright University issues a [Verifiable Credential](../../decentralised-identity/credentials/what-is-a-vc.md) to Jane through this peer-to-peer encrypted channel. The [Verifiable Credential](../../decentralised-identity/credentials/what-is-a-vc.md) has the following claims:
+
+* This is Jane Doe's diploma
+* Jane Doe graduated from Bright University in the year 2022
+* Jane Doe achieved a First Class Honours in her MSC degree in Computer Science.
+* **$20.00 ($CHEQ or stablecoin)** must be paid to Bright University to validate and verify the status pof the credential.&#x20;
+
+The Verifiable Credential has a proof, meaning it is digitally signed by the Public DID of Bright University, as well as potentially cryptographic material referring to a specific public key, which may be used for a particular purpose (such as asserting claims).
+
+<figure><img src="../../.gitbook/assets/Premium Credential Issued to Jane.png" alt=""><figcaption><p>Premium Credential issued to Jane's wallet</p></figcaption></figure>
+
+Jane receives the [Verifiable Credential](../../decentralised-identity/credentials/what-is-a-vc.md) to her digital identity wallet and  this entire data flow takes place off-ledger. This is important because it keeps all of Jane's personal information private, and only with her.
+
+Jane now holds a Verifiable Credential of her University degree in her digital identity wallet and is able to use this to prove claims about herself.
+
+#### Verifiable Presentation flow
+
+Jane applies online for a new job as a Lead Engineer at a leading technology company.
+
+The technology company asks for Jane to upload her education records. Rather than filling out the form manually; Jane scans another QR code to create a peer-to-peer encrypted channel with the technology company. Jane sends a [Verifiable Presentation](../../decentralised-identity/credentials/what-is-a-vp.md) containing her claims and the attached proof to those claims, in a few clicks or taps.
+
+The technology company is only able to verify the validity of the claims that Jane presents by resolving the DID embedded in the Presentation **and by paying $20.00 to Bright University** to verify the Credential's legitimacy, status and validity.
+
+<figure><img src="../../.gitbook/assets/Paying for Premium Credential.png" alt=""><figcaption></figcaption></figure>
+
+Through paying to verify the credential, the technology company is able to see the DID Document and also the Credential status information stored as a DID-Linked Resource. Automatically, the technology company is able to ascertain that the proof inside Jane's Verifiable Presentation was issued by the real Bright University and is for the correct purpose.
+
+The technology company is now satisfied and progresses Jane to the next phase of the application.
+
+On the other side, Bright University make $20.00, which they can later withdraw into fiat currency. This creates a trusted relationship between the "Verifier" (technology company) and the "Issuer" (Bright University) whereby a fair payment can be made for cryptographically verifiable data that makes the technology companies recruitment process much easier.