Issue Credential
Issue conformant W3C Verifiable Credentials over REST API
Using the
/credential/create API, it is possible to issue Verifiable Credentials, signed by a cheqd DID, in a few clicks or lines of code. Make sure you have set up your account with Credential Service and are logged in, using our guide below:
Before you can issue a Verifiable Credential, you need to create an Issuer DID which is used to sign the Credential payload. Use the API in the page below to create an Issuer DID:
Again, before you issue a Verifiable Credential, you need to know to whom you are issuing it. If you need to create a Subject DID, you can take a look at the page here:
Within the JSON object of the API request, you will need to input the
issuer and subject information, as well as the attributes which you want to issue in the Credential. You may also want to add additional fields such as a credentialSchema.post
/credential/issue
Issue a Verifiable Credential
Users have two options for compiling the Credential bodies and issuing Verifiable Credentials:
- 1.Filling out a simple form using the
application/x-www-url-form-encodedoption on the Swagger UI. - 2.Compiling a Credential body yourself using the
application/jsonoption on the Swagger UI.
This is the easiest way to issue Credentials and is recommended for users who are not overly familiar with compiling JSON objects.
Using the
application/x-www-url-form-encoded option on the Swagger UI, users are able to choose between the following variables and options to issue Verifiable Credentials:This is the DID of the Credential issuer, created in Step 2. This needs to be a
did:cheqd DID. For example:did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0
These are the claims or attributes attested to within the Verifiable Credential. This must be a JSON object, following the syntax defined in the Verifiable Credential Data Model. For example:
{
"name": "Bob",
"gender": "male"
}
This is an optional property that defines semantic information about the Credential, conforming to the @contexts section of the Verifiable Credential Data Model. For example:
https://www.w3.org/2018/credentials/v1
This is an optional property that defines information about the type of Verifiable Credential, conforming to the types section of the Verifiable Credential Data Model. For example:
VerifiableCredential
This is an optional property that defines information about the expiration date of a Verifiable Credential, conforming to the expiration section of the Verifiable Credentials Data Model. For example:
2023-06-08T13:49:28.000Z
credentialStatus properties for VC revocation or suspension. Takes statusListName and statusListPurpose as inputs. If you have already created a Status List, you can include the same inputs here to map this issued credential within the created bitstring. Note that this is the same for unencrypted Status Lists and for encrypted Status Lists. For example:
{
"statusPurpose": "revocation",
"statusListName": "employee-credentials"
}
Below are a set of examples of alternative input parameters for users to specify the bitstring index of the issued Credential. The bitstring index is where exactly the issued credential will map to within the Status List. This should be noted and stored by the issuer to keep a record of which issued credentials are active, revoked or suspended:
Ensure that the
"statusPurpose" and "statusListName" is the same as the existing Status List on-ledger.Instead of using simple form variables, you can issue a Verifiable Credential using a JSON payload with the
application/json option on the Swagger UI. Below is an example of the request format for issuing a Verifiable Credential using a custom JSON payload, including some of the possible parameters:
{
"issuerDid": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"subjectDid": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"attributes": {
"gender": "male",
"name": "Bob"
},
"@context": [
"https://schema.org"
],
"type": [
"Person"
],
"format": "jwt",
"credentialStatus": {
"statusPurpose": "revocation",
"statusListName": "employee-credentials",
"statusListIndex": 10
}
}
Execute the API below to issue a Verifiable Credential, signed by your issuer DID.
post
/credential/issue
Issue a Verifiable Credential
This endpoint issues a Verifiable Credential. As input it takes the list of issuerDid, subjectDid, attributes, and other parameters of the credential to be issued.
Parameters
No parameters
Body
Example
Schema
{
"issuerDid": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
"subjectDid": "did:key:z6MkhaXgBZDvotDkL5257faiztiGiC2QtKLGpbnnEGta2doK",
"attributes": {
"gender": "male",
"name": "Bob"
},
"@context": [
"https://schema.org"
],
"type": [
"Person"
],
"format": "jwt",
"credentialStatus": {
"statusPurpose": "revocation",
"statusListName": "employee-credentials",
"statusListIndex": 10
}
}
application/x-www-form-urlencoded
Responses
200: OK
The request was successful.
400: Bad Request
A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.
401: Unauthorized
Access token is missing or invalid
500: Internal Server Error
An internal error has occurred. Additional state information plus metadata may be available in the response body.
Below are a list of alternatives for using Credentials with cheqd support. Each offers a different set of protocols and underlying technical capabilities.
t