1 of 9

Create Status Lists

Create, update and fetch Status Lists on cheqd, stored as DID-Linked Resources (DLRs).

Status Lists are generally sets of indices which can be used to mathematically derive whether an issued Credential has been revoked, suspended or is still valid. Status Lists are crucial for verifier applications to determine whether to accept a credential, presented by a holder.

What options do I have for creating status lists on cheqd?

There are many different ways to create status lists on cheqd, with options for easy integration (e.g. cheqd Studio) and more bespoke integrations (e.g. Credo and Veramo). Below are a list of options for creating cheqd DIDs.

Get started with cheqd Studio

There are two predominant Status List formats supported in cheqd Studio. Please choose a Status List type below to get started.

Bitstring Status List

Get started

Understanding Bitstring Status List

The Bitstring Status List supported in cheqd Studio utilise bitstrings to represent whether a Verifiable Credential has been suspended/revoked or not. A bitstring can be thought of as a long list of 1s and 0s, where, if the binary value of the position in the list is 1 (one), the verifiable credential is revoked, if it is 0 (zero) it is not revoked.

Figure 1: Graphic showing the Bitstring Status List bitstring

Each issued Credential correlates with a position and index on the bitstring, so that a verifier will be able to correlate the value within the Credential against the public bitstring to ascertain whether the Credential has been revoked or not, using a validate algorithm as well as a bitstring expansion algorithm.

Where is the StatusList usually published?

The issuer keeps a bitstring list of all Verifiable Credentials it has issued. The Status List is usually published by the issuer in the format of its own Verifiable Credential. This Verifiable Credential is generally hosted publicly on a centralised server or domain to enable third-party read-access.

Where does cheqd store the Status List?

cheqd stores each Status List and subsequent entries on-ledger as DID-Linked Resource versions. This has notable benefits, including the provenance, legitimacy and security of the Status List. For a full list of benefits, see the context for creating DID-Linked Resources.

Create Bitstring Status List

Create a Bitstring Status List as a DID-Linked Resource (DLR) on cheqd, using cheqd Studio.

Users are able to create Bitstring Status List entries on-ledger, in order to revoke or suspend Verifiable Credentials. This is a derivation from the core spec made by cheqd to support a more decentralized and resilient approach to storing Status Lists.

Step 1: Set up your account

Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:

Step 2: Create a DID

Before you can create a Status List, you need to create a DID which is used to link the Status List on-ledger. Use the API in the page below to create a DID:

Step 3: Select the unencrypted Status List API

When , a user will have the following options:

/credential-status/create/encrypted

Using this API will encrypt the bitstring of the Status List, meaning that a set of Payment Conditions will need to be met in order to access the Status List contents.

/credential-status/create/unencrypted

Using this API will create a regular Status List on-ledger, where the contents of the Status List are visible to any users who queries the blockchain.

For the purpose of this tutorial, we will assume the user is creating an unencrypted Status List. For encrypted Status Lists, .

Step 4: Create unencrypted Status List

Using the /credential-status/create/unencrypted API, users have two options for creating an encrypted Status List on-ledger:

Filling out a simple form using the application/x-www-url-form-encoded option within an API client of your choice.
Compiling a Status List payload yourself using the application/json option within an API client of your choice.

Option 1. Choose from a few variables and we will compile the Status List for you

This is the easiest way to create unencrypted Status Lists on cheqd and is recommended for users who are not overly familiar with compiling JSON objects.

Using the application/x-www-url-form-encoded option, users are able to choose between the following variables and options to create an unencrypted Status List on-ledger:

statusPurpose (required)

revocation (creates a Status List where each entry refers to revocation status)
suspension (creates a Status List where each entry refers to suspension status. Note that suspended Credentials may become unsuspended).

did (required)

Enter the Decentralized Identifier (DID) of the Status List publisher . For example:

statusListName (required)

This is the name of your Status List. This will also need to be kept consistent for all future updates of the same Status List. For example:

length (optional)

The length of the Status List to be created. The default and minimum length is 140000 which is 16kb. For example:

encoding (optional)

The encoding format of the encrypted StatusList DID-Linked Resource to be created.

base64url
base64
hex

statusListVersion (optional)

A user set value to represent the version of the Status List. For example:

alsoKnownAs (optional)

A user set field to assign a set of alternative URIs where the DID-Linked Resource can be fetched from. For example:

Option 2. Publish a JSON payload yourself

Instead of using simple form variables, you can create an encrypted Status List using a JSON payload yourself using the application/json option on the Swagger UI.

Request format

An example of the JSON payload needed to be submitted is below:

Step 5: Hit the API

Once the Issuer has populated the requisite information for the unencrypted Status List request, they can use the API below to submit it to the ledger.

Update Bitstring Status List

Update the indices of a Bitstring Status List as a DID-Linked Resource (DLR) on cheqd, using cheqd Studio.

The /credential-status/update/unencrypted API enables users to update the indices of a Status List. This may be useful for revoking Credentials in bulk, rather than submitting individual /credential/revoke requests.

Check Bitstring Status List

Query Bitstring Status List entries or indices using cheqd Studio.

Using the /credential-status/check API, users are able to query specific Credential indices within a Status List to ascertain whether the Credential is revoked, suspended or currently valid.

Step 1: Set parameters for check

Using the /credential-status/check API, users have two options for checking whether a particular Credential index is revoked or suspended:

Filling out a simple form using the application/x-www-url-form-encoded option on the Swagger UI.
Compiling a DID Document body yourself using the application/json option on the Swagger UI.

Option 1. Choose from a few variables

This is the easiest way to check whether a particular credential index is revoked or suspended.

Using the application/x-www-url-form-encoded option on the Swagger UI, users are able to choose between the following variables to compile your DID:

statusPurpose

The purpose of the status list that has already been created on-ledger. Can be:

revocation
suspension

did

DID of the StatusList2021 publisher, or the DID linked to the Status List resources. For example:

did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0

statusListName

The name of the existing Status List resource to be checked. For example:

employmentCredentialRevocationList

index

The index within the bitstring that the user wants to query. For example:

Make Fee Payment

To automatically make a payment to an Issuer in order to verify an encrypted Status List, follow the tutorial here:

Option 2. Publish a JSON Payload

Instead of using simple parameters, users can submit a JSON payload to the same effect using the application/json option on the Swagger UI. For example:

{
  "did": "string",
  "statusListName": "string",
  "index": 0,
  "makeFeePayment": false
}

Step 2: Execute the API request

Execute the API request using the API below:

Search Bitstring Status List

Search and filter for Bitstring Status List DID-Linked Resources (DLRs) using cheqd Studio.

The /credential-status/search API allows users to search for specific entries of a Status List on the cheqd network. For example, if there are multiple Status Lists associated with the same DID, the search functionality allows applications to make requests only to a specified Status List.

Step 1: Set Status List Search Filters

Users are able to filter by:

did (required)

The is the DID of the publisher of the Status List. The Status List entries will be DID-Linked Resources associated with this DID.

statusPurpose

The is the type of Status List to be queried. The options are:

revocation
suspension

statusListName

The is the name of the Status List. Alongside the statusPurpose, this will uniquely identify a version of the Status List.

Step 2: Hit the API

Execute the filters from Step 1 on the API below:

Token Status List

Get Started

Understanding Token Status List

Token Status List is a specification from the Internet Engineering Task Force, using JSON or CBOR encoded sets of bits and wrapping these as either a JSON Web Tokens (JWTs) or CBOR Web Tokens (CWTs), to comprise a full status list.

The link to the specification may be found here.

Create Token Status List

Create a Token Status List JWT or CWT as a DID-Linked Resource (DLR), using cheqd Studio.

Users are able to create Token Status List entries on-ledger, which may be used to represent whether a Verifiable Credential is active, inactive or suspended. This implementation on cheqd is a derivation from the core spec made by cheqd to support a more decentralised and resilient approach to storing Token Status Lists.

Step 1: Set up your account

Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:

Step 2: Create a DID

Before you can create a Status List, you need to create a DID which is used to link the Status List on-ledger. Use the API in the page below to create a DID:

Step 3. Create your Status List JWT/CWT and save the file locally

Token Status Lists are JWT or CWT files that reference lists of bits formatted in JSON or CBOR.

Non-normative example for a Status List Token in JWT format

{
  "alg": "ES256",
  "kid": "12",
  "typ": "statuslist+jwt"
}
.
{
  "exp": 2291720170,
  "iat": 1686920170,
  "iss": "https://example.com",
  "status_list": {
    "bits": 1,
    "lst": "eNrbuRgAAhcBXQ"
  },
  "sub": "https://example.com/statuslists/1"
}

Non-normative example for a Status List Token in CWT format (not including the type header yet)

d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
56a2646269747301636c73744a78dadbb918000217015d58400f2ca3772e10b09d5d
6ed56461f7cba1a816c6234072d1bb693db277048e5db5a4e64444492a9b781d6c7a
c9714db99cc7aadb3812ec90cab7794170bab5b473

Save this file locally and call it something like statusListToken.json

Note that each JWT or CWT must be below ~45kb in size.

Step 4: Encode the file

Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:

$ base64 -w 0 resource.json
<path-to-the-resource-file>

Expected output:

$ base64 -w 0 resource.json
SGVsbG8sIHdvcmxk

Step 5: Set the resource name and type

DID-Linked Resources are grouped by having identical names and types. This means if you want to create a new version of the same Resource, you will need to specify the same name and type in the following request.

For Token Status Lists, the "type" MUST be: "TokenStatusList".

For example:

{
    "data": "SGVsbG8sIHdvcmxk",
    "encoding": "base64url",
    "name": "DegreeCredentialStatus",
    "type": "TokenStatusList"
}

Step 6: Populate the request inputs and hit the API

Ensure that you link this Token Status List to the DID that you created in step 3. This will sign the resource with the same verification method keys in your DID Document, ensuring cryptographic integrity and Controllership of the Status List.

As a DID-Linked Resource, the Token Status List will have a fully resolvable DID URL which can be referenced within the body of Verifiable Credentials, and queried by verification policies to establish the status of the specific credential.

Step 7: Reference the Token Status List

Owing to the design of DID-Linked Resources, following the creation of the Token Status List, users are able to reference the specific version, or create a query to always fetch the latest version of the Token Status List.

Using a DID Resolver or the search DID endpoint, users can find the DID URL and unique resourceId of the Token Status List. The unique resourceId allows users to specify this exact version of the Token Status List.

In the DID Document Metadata, users should find "linkedResourceMetadata", like the following snippet:

"linkedResourceMetadata": [
      {
        "resourceURI": "did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d/resources/4e1104f9-2ee9-4bde-adc2-ab8ba72b124a",
        "resourceCollectionId": "0a5b94d0-a417-48ed-a6f5-4abc9e95888d",
        "resourceId": "4e1104f9-2ee9-4bde-adc2-ab8ba72b124a",
        "resourceName": "DegreeCredentialStatus",
        "resourceType": "TokenStatusList",
        "mediaType": "application/json",
        "resourceVersion": "",
        "created": "2023-03-24T12:13:45Z",
        "checksum": "6819aaecd4073173b159fedf8077c38e14939d03d58e7f4e2a0ddfe034eb2ed4",
        "previousVersionId": null,
        "nextVersionId": null
      }

Specific version of the Token Status List

Here, the "resourceURI" specifies the DID URL of the specific Token Status List that was created.

Latest version of the Token Status List

In order to reference the latest version of the Token Status List, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList

Token Status List at specific point in time

In order to reference the Token Status List at a particular point in time, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>&resourceVerionTime=<XMLDateTime>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList&resourceVersionTime=2023-02-22T06:58:18.61Z

Update Token Status List

Update a Token Status List JWT or CWT as a new DID-Linked Resource (DLR), using cheqd Studio.

Step 1. Manually create your new Status List JWT/CWT and save the file locally

Create a JWT or CWT file with the updated indices and bits for the updated Status List.

Non-normative example for a Status List Token in JWT format

{
  "alg": "ES256",
  "kid": "12",
  "typ": "statuslist+jwt"
}
.
{
  "exp": 2291720170,
  "iat": 1686920170,
  "iss": "https://example.com",
  "status_list": {
    "bits": 3,
    "lst": "eNrbuRgAAhcBXQHutdpRiBFREinSjQfeTpXmdQfwefegD"
  },
  "sub": "https://example.com/statuslists/1"
}

Non-normative example for a Status List Token in CWT format (not including the type header yet)

d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
56a2646269747301636c73744a78dadbb918000217015d58400f2ca3772e10b09d5d
6ed56461f7cba1a816c6234072d1bb693db277048e5db5a4e64444492a9b781d6c7a
c9714db99cc7aadb3812ec90cab7794170bab5b473

Save this file locally and call it something like statusListTokenUPDATED.json

Note that each JWT or CWT must be below ~45kb in size.

Step 2: Encode the updated file

Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:

$ base64 -w 0 resource.json
<path-to-the-resource-file>

Expected output:

$ base64 -w 0 resource.json
HfSynOpmBrhgfYguING

Step 3: Set the same Resource Name and Type

To create a new version you must use the same "name" and "type" for your resource, and ensure that the new Token Status List resource is being created underneath the same DID as your initial DID. You will also need to be logged into the same cheqd Studio account that you used to create the initial Token Status List to have access to the keys to sign the update.

For Token Status Lists, the "type" MUST be: "TokenStatusList".

For example:

{
    "data": "HfSynOpmBrhgfYguING",
    "encoding": "base64url",
    "name": "DegreeCredentialStatus",
    "type": "TokenStatusList"
}

Step 4: Populate the request inputs and hit the API

Create Token Status List

Create a Token Status List JWT or CWT as a DID-Linked Resource (DLR), using cheqd Studio.

Step 1: Set up your account

Make sure you have set up your account with cheqd Studio and are logged in, using our guide below:

Step 2: Create a DID

Before you can create a Status List, you need to create a DID which is used to link the Status List on-ledger. Use the API in the page below to create a DID:

Step 3. Create your Status List JWT/CWT and save the file locally

Token Status Lists are JWT or CWT files that reference lists of bits formatted in JSON or CBOR.

Non-normative example for a Status List Token in JWT format

{
  "alg": "ES256",
  "kid": "12",
  "typ": "statuslist+jwt"
}
.
{
  "exp": 2291720170,
  "iat": 1686920170,
  "iss": "https://example.com",
  "status_list": {
    "bits": 1,
    "lst": "eNrbuRgAAhcBXQ"
  },
  "sub": "https://example.com/statuslists/1"
}

Non-normative example for a Status List Token in CWT format (not including the type header yet)

d28453a20126106e7374617475736c6973742b637774a1044231325860a502782168
747470733a2f2f6578616d706c652e636f6d2f7374617475736c697374732f310173
68747470733a2f2f6578616d706c652e636f6d061a648c5bea041a8898dfea19fffe
56a2646269747301636c73744a78dadbb918000217015d58400f2ca3772e10b09d5d
6ed56461f7cba1a816c6234072d1bb693db277048e5db5a4e64444492a9b781d6c7a
c9714db99cc7aadb3812ec90cab7794170bab5b473

Save this file locally and call it something like statusListToken.json

Note that each JWT or CWT must be below ~45kb in size.

Step 4: Encode the file

Prepare a file with resource and encode it into base64, base64url or hex. On Unix systems, you can use the following command input:

$ base64 -w 0 resource.json
<path-to-the-resource-file>

Expected output:

$ base64 -w 0 resource.json
SGVsbG8sIHdvcmxk

Step 5: Set the resource name and type

For Token Status Lists, the "type" MUST be: "TokenStatusList".

For example:

{
    "data": "SGVsbG8sIHdvcmxk",
    "encoding": "base64url",
    "name": "DegreeCredentialStatus",
    "type": "TokenStatusList"
}

Step 6: Populate the request inputs and hit the API

Step 7: Reference the Token Status List

In the DID Document Metadata, users should find "linkedResourceMetadata", like the following snippet:

"linkedResourceMetadata": [
      {
        "resourceURI": "did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d/resources/4e1104f9-2ee9-4bde-adc2-ab8ba72b124a",
        "resourceCollectionId": "0a5b94d0-a417-48ed-a6f5-4abc9e95888d",
        "resourceId": "4e1104f9-2ee9-4bde-adc2-ab8ba72b124a",
        "resourceName": "DegreeCredentialStatus",
        "resourceType": "TokenStatusList",
        "mediaType": "application/json",
        "resourceVersion": "",
        "created": "2023-03-24T12:13:45Z",
        "checksum": "6819aaecd4073173b159fedf8077c38e14939d03d58e7f4e2a0ddfe034eb2ed4",
        "previousVersionId": null,
        "nextVersionId": null
      }

Specific version of the Token Status List

Here, the "resourceURI" specifies the DID URL of the specific Token Status List that was created.

Latest version of the Token Status List

In order to reference the latest version of the Token Status List, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList

Token Status List at specific point in time

In order to reference the Token Status List at a particular point in time, the following construction needs to be used:

did:cheqd:<namespace>:<resourceCollectionId>?resourceName=<resourceName>&resourceType=<resourceType>&resourceVerionTime=<XMLDateTime>

For example:

did:cheqd:testnet:0a5b94d0-a417-48ed-a6f5-4abc9e95888d?resourceName=DegreeCredentialStatus&resourceType=TokenStatusList&resourceVersionTime=2023-02-22T06:58:18.61Z

Resolve a DID Document.

get

/did/search/{did}

Resolve a DID Document by DID identifier. Also supports DID Resolution Queries as defined in the W3C DID Resolution specification.

Authorizations

x-api-keystringRequired

Path parameters

didstringRequired

DID identifier to resolve.

Example: did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0

Query parameters

metadatabooleanOptional

Return only metadata of DID Document instead of actual DID Document.

versionIdstring · uuidOptional

Unique UUID version identifier of DID Document. Allows for fetching a specific version of the DID Document. See cheqd DID Method Specification for more details.

Example: 3ccde6ba-6ba5-56f2-9f4f-8825561a9860

versionTimestring · date-timeOptional

Returns the closest version of the DID Document at or before specified time. See DID Resolution handling for did:cheqd for more details.

Example: 1970-01-01T00:00:00Z

transformKeysstring · enumOptional

This directive transforms the Verification Method key format from the version in the DID Document to the specified format chosen below.

Possible values:

servicestringOptional

Query DID Document for a specific Service Endpoint by Service ID (e.g., service-1 in did:cheqd:mainnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1). This will typically redirect to the Service Endpoint based on DID Resolution specification algorithm.

Example: service-1

relativeRefstringOptional

Relative reference is a query fragment appended to the Service Endpoint URL. Must be used along with the service query property above. See DID Resolution specification algorithm for more details.

Example: /path/to/file

Responses

200

The request was successful.

application/json

400

A problem with the input fields has occurred. Additional state information plus metadata may be available in the response body.

401

Access token is missing or invalid

500

An internal error has occurred. Additional state information plus metadata may be available in the response body.

get

/did/search/{did}

GET /did/search/{did} HTTP/1.1
Host: studio-api.cheqd.net
x-api-key: YOUR_API_KEY
Accept: */*

{
  "@context": "https://w3id.org/did-resolution/v1",
  "didDidResolutionMetadata": {
    "contentType": "application/did+ld+json",
    "retrieved": "2021-09-01T12:00:00Z",
    "did": {
      "didString": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
      "method": "cheqd",
      "methodSpecificId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47"
    }
  },
  "didDocument": {
    "@context": [
      "https://www.w3.org/ns/did/v1"
    ],
    "id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
    "controller": [
      "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0"
    ],
    "verificationMethod": [
      {
        "id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1",
        "type": "Ed25519VerificationKey2018",
        "controller": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0",
        "publicKeyBase58": "z6MkkVbyHJLLjdjU5B62DaJ4mkdMdUkttf9UqySSkA9bVTeZ"
      }
    ],
    "authentication": [
      "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#key-1"
    ],
    "service": [
      {
        "id": "did:cheqd:testnet:7bf81a20-633c-4cc7-bc4a-5a45801005e0#service-1",
        "type": "LinkedDomains",
        "serviceEndpoint": [
          "https://example.com"
        ]
      }
    ]
  },
  "didDocumentMetadata": {
    "created": "2021-09-01T12:00:00Z",
    "deactivated": false,
    "updated": "2021-09-10T12:00:00Z",
    "versionId": "3ccde6ba-6ba5-56f2-9f4f-8825561a9860",
    "linkedResourceMetadata": [
      {
        "resourceURI": "did:cheqd:testnet:55dbc8bf-fba3-4117-855c-1e0dc1d3bb47/resources/398cee0a-efac-4643-9f4c-74c48c72a14b",
        "resourceCollectionId": "55dbc8bf-fba3-4117-855c-1e0dc1d3bb47",
        "resourceId": "398cee0a-efac-4643-9f4c-74c48c72a14b",
        "resourceName": "cheqd-issuer-logo",
        "resourceType": "CredentialArtwork",
        "mediaType": "image/png",
        "resourceVersion": "1.0",
        "checksum": "a95380f460e63ad939541a57aecbfd795fcd37c6d78ee86c885340e33a91b559",
        "created": "2021-09-01T12:00:00Z",
        "nextVersionId": "d4829ac7-4566-478c-a408-b44767eddadc",
        "previousVersionId": "ad7a8442-3531-46eb-a024-53953ec6e4ff"
      }
    ]
  }
}