How to use existing credential schemas with Disco.
What is a Schema?
A schema is central to Verifiable Credentials as it defines the structure and content. Specifically, schemas are representations of a particular type of credential. See more details on the credential data model hereCredential Data Model.
Credential schemas generally have these components:
$id - the URL where the schema is located
description - a long description of the credential type that this schema was defined for
credentialSubject - this section is unique to the credential and holds the fields relevant for creating a particular credential type, see detailed examples below
expirationDate - the expiration date of the credential, if applicable
issuanceDate the date and time the credential was issued
title - the short description of the credential type
Benefit
A schema enables you to have a consistent structure that can be easily verified by a third party (ie. data verification)
CredentialSubject
Schemas per W3C Verifiable Credential spec includes a vast amount of metadata. With that in mind we will be focusing on pieces relevant to most developers - credentialSubject.
The credentialSubject is the entity like person or organization which the credential makes claims about such as their name, age, or contributions.
{
...
"credentialSubject": { // The Verifiable Credential payload object. This is where all fields pertaining to the specific credential type resides.
"properties": {
"expiration": { // Standard to the W3C VC protocol - an optional expiration date for the Credential.
"format": "date",
"title": "Expiration",
"type": "string"
},
"id": ... , // Standard to the W3C VC protocol - a unique credential identifier assigned by the system. As a developer you do NOT include this in API calls for creating your Credential.
"memberId": { // Optional and unique to this particular schema - use whatever membership ID you want to refer to - or may be left out if not used.
"title": "Member ID",
"type": "string"
},
"membershipDescription": { // Optional and unique to this particular schema - describe what the membership is for to the recipient and verifiers - or may be left out if not used.
"title": "Membership Description",
"type": "string"
},
"membershipLevel": { // Optional and unique to this particular schema - if your membership is hierarchical you can use this to indicate the level - or may be left out if not used.
"title": "Membership Level",
"type": "string"
},
"membershipType": { // Optional and unique to this particular schema - can be used to describe the membership type issued- or may be left out if not used.
"title": "Membership Type",
"type": "string"
},
"organization": { // Required and unique to this particular schema - the name of the organization for which this membership is issued for.
"title": "Organization Name",
"type": "string"
}
},
"required": [ // Required fields Unique to this particular schema
"id", // ALWAYS system generated
"organization" // Provided by you, the developer
],
"type": "object"
},
...
}
As mentioned above, much of this is boilerplate per W3C specification, what is unique to Membership Credential (and any other schemas for that matter) is in the CredentialSubject object. Note that the last object, named required in the CredentialSubject list the fields that must be provided for this particular schema.
Schema Examples
Proof of Mint: for users who are the first to mint an NFT
The payload object to use in API calls for Proof of Mint Credential - the rest is boilerplate.
"credentialSubject": {
"properties": {
"chain": { // Optional Proof of Mint field for credential creation
"title": "Chain",
"type": "string"
},
"contractAddress": { // Optional Proof of Mint field for credential creation
"title": "Contract address",
"type": "string"
},
"dateOfMint": { // Optional Proof of Mint field for credential creation
"format": "date",
"title": "Date of Mint",
"type": "string"
},
"id": { // DO NOT INCLUDE - a unique credential identifier assigned by the system. As a developer you do NOT include this in API calls for creating your credential.
"format": "uri",
"title": "Recipient DID",
"type": "string"
},
"tokenStandard": { // Optional Proof of Mint field for credential creation
"title": "Token Standard",
"type": "string"
}
},
"required": [ // Note that no Proof of Mint specific fields are required
"id"
],
"type": "object"
},
Beta User Credential: for users who are or have used your Beta products
The payload object to use in API calls for Beta User Credentials - the rest is boilerplate.
"credentialSubject": {
"properties": {
"id": {{ // DO NOT INCLUDE - a unique credential identifier assigned by the system. As a developer you do NOT include this in API calls for creating your Credential.
"title": "Recipient DID",
"type": "string"
},
"name": { // Optional Beta User field for Credential creation
"title": "Name",
"type": "string"
}
},
"required": [
"id"
],
"type": "object"
},
Snaps: Send Snaps To Celebrate Someone Doing Something Positive and Helpful
The payload object to use in API calls for Snaps Credential - the rest is boilerplate.
"credentialSubject": {
"properties": {
"id": { // DO NOT INCLUDE - a unique credential identifier assigned by the system. As a developer you do NOT include this in API calls for creating your Credential.
"title": "Recipient DID",
"type": "string"
},
"snapsType": { // Required enum for Snaps Credential creation
"enum": [
"Immaculate Vibes: Thank you for your awesome energy",
"Problem Solver: Thank you for working with me to solve a tough challenge together",
"Miracle Worker: Thank you for unexpectedly and proactively doing something awesome that impacted my day for the better!"
],
"title": "Snaps Type",
"type": "string"
}
},
"required": [
"id",
"snapsType"
],
"type": "object"
},
