CHIP-0016: VC1 Standard

CHIPs/chip-0016.md

@@ -0,0 +1,199 @@
+CHIP Number   | 0016
+:-------------|:----
+Title         | VC1 Standard
+Description   | A standard for implementing Verifiable Credentials on Chia's blockchain
+Author        | [Matt Hauff](https://github.com/Quexington)
+Editor        | [Dan Perry](https://github.com/danieljperry)
+Comments-URI  | [PR #65](https://github.com/Chia-Network/chips/pull/65)
+Status        | Stagnant
+Category      | Standards Track
+Sub-Category  | Chialisp
+Created       | 2023-04-25
+Requires      | [0004](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0004.md), [Singleton Standard](https://chialisp.com/singletons "Chia's Singleton Standard (pre-CHIP)")
+Replaces      | None
+Superseded-By | None
+
+## Abstract
+Chia Verifiable Credentials (VCs) allow a user of Chia's blockchain to create a digital representation of a person's identity, qualifications, or other attributes that can be cryptographically verified by others. In order to obtain a VC, an individual or entity must make one or more factual claims to a credential issuer. The issuer is responsible for validating the claim(s), after which the VC is issued. To use a VC, a verifier asks for a valid, provable claim to be asserted in order for that verification to be complete.
+
+## Definitions
+Throughout this document, we'll use the following terms:
+* **Must, required, shall** – These words indicate an absolute requirement of the specification
+* **Must not, shall not** – These phrases indicate an absolute prohibition of the specification
+* **Should, recommended** – These words indicate something that is not a requirement of the specification, but the implications of not following it should be carefully considered beforehand
+* **Should not, not recommended** – These phrases indicate something that is not a prohibition of the specification, but the implications of following it should be carefully considered beforehand
+* **May** – This word indicates something that is optional. Interoperability between implementations must not be broken because of the choice to implement, or not to implement, this feature
+* **DID** – [Decentralized Identifier](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0004.md), a type of identifier that enables verifiable, decentralized digital identity
+
+## Motivation
+Verifiable Credentials are used to establish trust between parties by providing digital proof (typically in the form of a digital signature) of claims made by individuals or entities. VCs thus help to ensure that only authorized parties can perform specific transactions or access sensitive information. Thanks to cryptographic techniques, the information stored in VCs is kept secure -- it cannot be tampered with or forged.
+
+VCs require the following three entities:
+
+1. Credential holder - the individual or entity who has been issued, and currently holds, the VC
+    * Note - The W3C specification defines a [subject](https://www.w3.org/TR/vc-data-model/#dfn-subjects) as `A thing about which claims are made.` The holder and the subject are typically, but not always, the same entity
+2. Credential issuer - the entity that creates and signs the VC, thus asserting the claims about the holder's identity, attributes, or qualifications and provides a proof for those claims in a credential that is issued to the holder
+    * Note - This CHIP uses the W3C definition of a [Credential](https://www.w3.org/TR/vc-data-model/#dfn-credential): `A set of one or more claims made by an issuer.`
+3. Verifier - the entity that verifies the authenticity and validity of the VC by checking the cryptographic proofs, trustworthiness of the issuer, and the relevance of the claims to the context of the transaction or interaction
+
+### Use Cases
+
+Several of the many potential use cases for Chia VCs are outlined in this section.
+
+#### Restricted CATs
+
+VCs can be used to gate access to Restricted Chia Asset Tokens (CATs). This example use case may require a fourth entity in addition to the three listed above:
+
+4. Security issuer - the corporation, company, or other entity that wishes to issue Restricted CATs, for example, to limit the sale or trading of digital securities to those who fulfill the following requirements:
+    * They are at least 18 years old
+    * They are not a citizen or resident of the United States of America
+
+Only those who possess a VC which claims to fulfill each of the requirements shall have permission to purchase and sell Restricted CATs.
+
+#### Company Badges
+
+Companies may want to issue to each employee a credential which allows access to the company's facilities. This type of VC would only be active while the holder is employed by the company.
+
+For example, Company A could validate and issue a VC to Person X. The VC would make the claim that Person X is employed at Company A. The same company would have the ability to revoke the VC when Person X is no longer employed at the company.
+
+#### Academic Credentials
+
+Universities or trade certification courses can issue Verifiable Credentials that confirm the holder has attended and completed the necessary requirements to earn a degree, or has completed the trade certification course.
+
+For example, University A issues a digital diploma to Person X, one of their graduates. This digital diploma serves as a tamper-proof and decentralized record that Person X can present to confirm attendance and completion of the courses at University A.
+
+#### Healthcare
+
+A patient could store their medical history that has been verified by their healthcare provider, and share their medical history with another healthcare provider.
+
+For example, a patient might receive a Verifiable Credential that contains their medical history, such as their diagnoses, treatments, and medications. The credential might also include metadata that describes the credential's issuer, the schema that defines the properties of the credential, and the public key of the issuer. The patient can then present the credential to a healthcare provider, who can verify the credential by requesting it from the patient and verifying the signature and metadata against the decentralized ledger. If the verification succeeds, the healthcare provider can trust that the data is authentic and has not been tampered with.
+
+#### Supply Chain Management
+
+Supply chain management can use Verifiable Credentials to track the origin and authenticity of products and materials throughout the supply chain. For example, a company might issue a Verifiable Credential that contains information about a product, such as its origin, quality, and certifications. The credential might also include metadata that describes the credential's issuer, the schema that defines the properties of the credential, and the public key of the issuer. The credential can then be stored in a decentralized ledger, such as a blockchain or a distributed ledger, to create a tamper-proof and auditable record of the product's information.
+
+When the product moves through the supply chain, each participant can add their own Verifiable Credentials that attest to the product's condition, location, and ownership. For example, a shipping company might issue a Verifiable Credential that contains information about the product's shipment, such as the date of shipment, the carrier, and the destination. The credential can be signed and stored in the same decentralized ledger, allowing other participants to verify its authenticity and integrity.
+
+
+## Backwards Compatibility
+The VC1 standard is a new type of Chialisp singleton. It does not replace any existing standards and does not introduce any backward incompatibilities.
+
+## Rationale
+This section details the various components of the VC1 standard, which were chosen to support pseudonymity and regulatory compliance, as well as to be conformant with the [W3C standard for Verifiable Credentials](https://www.w3.org/TR/vc-data-model).
+
+Note that the design laid out in this section requires each category of VC to define its own data model to standardize the proofs that are created.
+
+#### Primary structure
+Chia VCs are singletons. This was the most logical structure to use because it allows proofs to be added or removed while persisting all other information.
+
+#### Proof storage
+We decided to structure the set of proofs of the claims stored inside of a VC as a Merkle tree. We chose this structure (as opposed to a list) for the following reasons:
+
+* **To preserve pseudonymity** – By using a Merkle tree, only the tree hash needs to be stored on chain. When looking up proofs, a Proof of Inclusion (another hash) is all that is required to be presented. Any third-party observers of the blockchain won't be able to identify who the VC corresponds to, but by definition, the credential issuer will know this information because they issued the VC
+* **To minimize the time complexity** – Searching for a proof in a list would be linear $\mathcal{O}(n)$, whereas providing a Proof of Inclusion in a Merkle tree is logarithmic $\mathcal{O}(\log(n))$.
+
+This structure also allows the security issuer to obtain the proofs contained within a VC from the credential issuer if required by submitting the singleton launcher ID to the credential issuer and requesting the corresponding proofs.
+
+#### Revocation
+In the event that a holder no longer complies with one or more claims contained within a VC, or if the issued VC has expired, the credential issuer should have a way to revoke the VC. (The holder's proof file can be used to determine the expiration date of a VC.) One option for revocation would be to "brick" the VC, rendering it unusable. However, because a VC is a singleton, it is possible for it to contain funds. There are currently no use cases that involve funding a VC, but at some point, such a use case could emerge. It is therefore not recommended for the VC to be bricked in the case of the revocation of credentials. Instead, the VC1 standard includes a recommended mechanism to revoke the proofs, while keeping the VC intact.
+
+In the event that revocation becomes necessary (for example, if the holder becomes a US citizen and they hold a claim declaring that they are _not_ a US citizen), the credential issuer can activate the revocation mechanism. This will cause all proofs contained within the VC (as well as a few other changes, as detailed in the [Specification section](#specification)) to be removed. The holder will still be able to access the VC (for example, to retrieve any funds contained within), but the proofs will no longer exist.
+
+A few relevant notes:
+* This mechanism stays with every generation of the coin until it is activated 
+* The credential issuer is recommended to include a revocation mechanism in their VC implementation, but this is not a requirement:
+  * The credential issuer may create a custom revocation mechanism
+  * The credential issuer may also choose not to include any revocation mechanism
+* In all cases, the holder should be made aware of the revocation mechanism (or lack thereof), as well as how it functions
+
+#### Workflow
+
+This section presents a basic workflow for acquiring and using a Chia Verifiable Credential. It uses an example of a company that wants to issue Restricted CATs to subjects who are:
+* Not citizens or residents of the United States of America
+* At least 18 years old
+
+The following roles will be used in this example:
+1. Credential subject/holder - the person who wishes to obtain a credential (the subject) or who is currently holding the credential (the holder)
+2. Credential issuer - the company that issues the credential
+3. Verifier and security issuer - the company that verifies the authenticity of the credential; also the company that issues Restricted CATs
+
+The following process will be used to obtain and use the VC in this example:
+1. The subject presents a copy of their passport and a utility bill to the credential issuer
+2. The credential issuer verifies the authenticity of the credentials. The passport contains the holder's date of birth, which is used to verify that the holder is at least 18 years old. The passport also shows the holder's nationality/citizenship. The utility bill is in the subject's name; this is used to verify the holder's residency
+3. Having been satisfied that the subject meets the necessary requirements, the credential issuer creates the VC, adds the necessary proofs, and delivers it to the subject. The subject is now the holder of the VC
+4. The holder applies with the security issuer to receive an issuance of Restricted CATs
+5. The security issuer verifies the authenticity and current validity of the credential
+6. The security issuer issues the Restricted CATs to the holder
+
+## Specification
+
+#### VC Structure
+* **Outer puzzle**: The outermost layer of a Verifiable Credential is the [singleton puzzle](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/singleton_top_layer_v1_1.clsp). Thus, all Chia VCs are required to be singletons
+
+* **NFT ownership layer**: The singleton's inner puzzle is a trimmed-down implementation of the [NFT ownership layer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/puzzles/nft_ownership_layer.clsp) that is used with the [NFT1 specification](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0005.md), including:
+  * **Metadata**: The ownership layer contains a [metadata layer](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/exigent_metadata_layer.clsp), which must be affirmed with each spend of the singleton. Only the credential issuer may modify this metadata
+  * **Merkle tree**: The ownership layer must contain a Merkle tree of proofs with the following structure:
+    * Each leaf in the tree corresponds to one proof
+    * Each proof is stored as a `(key, value)` pair
+    * Providers have the option to include whichever proof(s) they need. Because different providers will have different requirements, not all Merkle trees will be the same
+  * **Proof checking**: In order to show that a specific proof exists, the VC must reveal that its Merkle tree contains the leaf that corresponds to the required proof. This is called a "Proof of Inclusion," which the singleton then uses to authorize a transaction
+  * **Decentralized Identifier (DID)**: The singleton ID of the credential issuer's DID is also stored at the ownership layer. This DID will announce all changes whenever the singleton is spent. Multiple DIDs may be included in a single VC
+
+* **Transfer program (covenant adapter)**: The [covenant adapter](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/eml_transfer_program_covenant_adapter.clsp) included in this specification is required to be used. It adapts the API between the ownership layer and its transfer program when the transfer program is wrapped with a covenant layer. The covenant adapter calls [p2_announced_delegated_puzzle](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/p2_announced_delegated_puzzle.clsp), which announces the hash of the delegated puzzle. This ensures that the correct delegated puzzle is run (if a different puzzle is run, the spend will fail).
+
+* **Covenant layer**: The [covenant layer puzzle](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/covenant_layer.clsp) forces the credential issuer to create the VC with empty proofs. Later, the credential issuer should add all required proofs for their use case. Two puzzles are called from the Covenant layer:
+  * The [Parent Morpher](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/std_parent_morpher.clsp) is used when the covenant layer is the outermost layer of the coin
+  * The [Covenant Morpher](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/eml_covenant_morpher.clsp) is used to prove that the parent was a singleton
+
+#### Adding proofs
+In order to add proofs to a VC, the issuer:
+
+* Must be classified by the same DID ID that was included in the ownership layer (only the credential issuer's DID may add proofs to a VC)
+* Must have a singleton of their own that they can use to update the proofs. Any on-chain verification shall reference this singleton when they declare that they trust the credential issuer to provide the proofs
+
+The adding of proofs is enforced in the [update metadata](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/eml_update_metadata_with_DID.clsp) transfer program, which asserts an announcement made by a DID's singleton.
+
+The credential issuer must therefore perform the following actions to issue and transfer a VC to a holder:
+1. Create the VC without any proofs
+2. Add the relevant proofs to the VC
+3. Transfer the VC to the subject, who is now also the holder
+
+#### Revocation activation
+Credential issuers are recommended to use the included [revocation puzzle](https://github.com/Chia-Network/chia-blockchain/blob/main/chia/wallet/vc_wallet/vc_puzzles/viral_backdoor.clsp), which will remove all proofs. Only the credential issuer (and not the holder) can activate this revocation mechanism. When it is activated:
+* All proofs will be cleared from the VC
+* The proof provider will also be removed
+* The holder gains the ability to activate the transfer program's inner puzzle without restrictions
+* The revocation mechanism itself will also be removed
+
+At this point, the holder will gain full control of the singleton, which will no longer contain any proofs. The VC will therefore not be able to authorize any transactions. However, the VC will not be bricked, thus allowing the holder to recover any funds custodied therein. In the future, the holder could also add more proofs to the VC if desired.
+
+#### Allowed modifications
+Some features outlined in this CHIP could be modified while still conforming to the specification:
+
+* **Revocation**
+  * As previously stated, a credential issuer could swap out the standard revocation mechanism for a different revocation mechanism of their choosing
+
+* **Time-based VC expiration**
+  * Ideally, a credential issuer could enforce the expiration of VCs if desired
+  * As of this CHIP's creation, on-chain VC expiration is not yet possible. This is because coins (such as a VC's singleton) cannot become invalid with time
+  * With the activation of [CHIP 14](https://github.com/Chia-Network/chips/blob/main/CHIPs/chip-0014.md), it will become possible to create VCs that expire. This will be enforced on-chain, thus enabling automatic revocation of VCs after an expiration time stamp or block height has passed
+
+* **Global VC expiration**
+  * Ideally, a credential issuer could change a value to force all VCs that use a specific data schema (as defined in the [W3C specification](https://www.w3.org/TR/vc-data-model/#data-schemas)) to expire
+  * This feature would require singleton spend aggregation, which is currently in development
+
+## Test Cases
+Test cases for Chia Verifiable Credentials are located on GitHub, in the [/chia/_tests/wallet/vc_wallet](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/_tests/wallet/vc_wallet) folder of the `chia-blockchain` repository.
+
+## Reference Implementation
+The reference implementation for Chia Verifiable credentials is located on GitHub, in the [/chia/wallet/vc_wallet](https://github.com/Chia-Network/chia-blockchain/tree/main/chia/wallet/vc_wallet) folder of the `chia-blockchain` repository.
+
+## Security
+* There currently are plans to conduct a security audit of the source code from this CHIP
+* As for privacy, the specification from this CHIP does not take a stance. Proofs may or may not contain personally identifiable information. The credential issuer, the holder, and the verifier must decide what information is appropriate to request, give, and verify regarding VCs
+
+## Additional Assets
+* [VC Puzzle Stack](/assets/chip-0016/VC_Puzzle_Stack.png)
+
+## Copyright
+Copyright and related rights waived via [CC0](https://creativecommons.org/publicdomain/zero/1.0/).