Credentials
You can create and sign Verifiable Credentials on Dock Certs and its API. By default, Dock does not store the credential - only its metadata. You can choose to persist a credential, in which case we will encrypt and store the credential for later retrieval using a password. Verifiable Credentials are cryptographically secure and tamper-proof. Once issued, they cannot be edited.
The Dock API supports issuing two types of credentials. The native Dock Verifiable Credentials and Polygon ID Verifiable Credentials.
For Polygon ID credentials:
In order to issue Polygon ID credentials, the issuer must be a
did:polygonid
issuer.Polygon ID credentials do not support designs at this point so
template
field should be omitted.
Endpoints
POST /credentials GET /credentials/{id} DELETE /credentials/{id}
Issue Credential
Creates and issues a JSON-LD Verifiable Credential that conforms to the W3C VCDM specification. The type
values and subject properties must be represented by a schema URI in the context
property. If you do not specify a context
property, the API will automatically generate an embedded JSON-LD context based on the properties within your credential. You can read more about JSON-LD and contexts here.
The https://www.w3.org/2018/credentials/v1
context URI is always required and will be supplied by default at all times as mandated by the spec. If you pass a custom context, you must ensure that you define all the required JSON-LD terms. Please also note that the request format here is not the same as an issued verifiable credential. You can issue to multiple subjects per credential by passing an array of objects.
To sign a credential, an issuer
must be supplied as either a fully qualified DID string or an object with at least an id
property which is a fully qualified DID. (e.g: did:dock:xyz
)
The issuer
property must be a DID that you control with Dock Certs.
By default, Dock does not store the credential contents at all - only minimal credential metadata. You can choose to set the persist
value to true
and provide a password
string which will store the credential contents encrypted on our platform. The following metadata is stored on each issuance:
Credential ID property
Credential size in bytes
Issuer DID
Issuance date
For a detailed example of the credential workflow. Please refer here.
Zero Knowledge Proofs (ZKP)
Dock credentials support anonymous credentials using Zero Knowledge Proofs and Selective Disclosure by using the BBS2023 signing algorithm when issuing the credential. To enable this functionality, simply set the algorithm
field in the request to BBS2023
.
Credential Distribution
Dock's API has built in credential distribution on issuance, allowing you to send credentials directly to a holder's email and/or Dock-compatible wallet. You can achieve this by supplying the recipientEmail
field and distribute: true
in your request. For DID distribution, simply set the credentialSubject.id
property to the holder's DID.
Revocation
In order to support revocation the credential must be linked to a revocation registry at the time of issuance. To link the revocation registry to the credential set the status
field in the Credential body to the registry.id
value.
This operation counts towards your monthly transaction/credential issuance limit for each successful call
Parameters
Name | In | Type | Required | Description |
---|---|---|---|---|
anchor | body | boolean | false | Whether to anchor the credential on the blockchain as soon as it is issued. Defaults to false. |
persist | body | boolean | false | Whether to store an encrypted version of this credential with us. Defaults to false, if true you must supply password. |
password | body | string | false | Password used to encrypt the credential if you choose to store it. The same password must be used to retrieve the credential contents. Dock does not store this password. |
template | body | UUID string | false | The ID of the intended template/design, optional |
format | body | string | false | Specifies the output format of the credential, either |
algorithm | body | string | false | Specifies which signing algorithm to use to sign the issued credential. Defaults to |
distribute | body | boolean | false | Whether to use credential distribution to DID/email, optional |
recipientEmail | body | string | false | The holder's email for email distribution |
credential | body | true | Credential object as described in the schema. |
Enumerated Values
Parameter | Value | Description |
---|---|---|
algorithm | ed25519 or secp256k1 or sr25519 or dockbbs+ | The algorithm used to sign the credential. |
Responses
Status | Meaning | Description | Schema |
---|---|---|---|
200 | The request was successful and returns the created Verifiable Credential. | ||
400 | The request was unsuccessful, because of invalid/insufficient credential params. | ||
401 | The request was unsuccessful, either because the authorization token was missing/invalid or you don't own the DID. | ||
402 | Transaction limit reached or upgrade required to proceed |
Request Claims
Creates a request to gather certain claims and then issues the holder a credential after submission. The claims are user provided and type is based on the schema provided. This can be useful to catch a subject's DID without knowing it beforehand, name or other field. It should only be used when you do not already know this data or cannot find it by other means. There is a risk that a user may enter false data - so use it sparingly and not for fields that are important.
Typically, once the request has been created, you would show the holder the QR URL as an image or deep link for them to scan with a wallet and enter claims.
This operation counts towards your monthly transaction/credential issuance limit for each successful call.
Parameters
Name | In | Type | Required | Description |
---|---|---|---|---|
schema | body | string | false | Schema URL for the issued credential |
claims | body | array | false | The list of claims for the subject |
credentialOptions | body | true | Credential issue parameters. |
Responses
Status | Meaning | Description | Schema |
---|---|---|---|
200 | The request was successful and returns the claims request properties. | ||
400 | The request was unsuccessful, because of invalid/insufficient credential params. | ||
401 | The request was unsuccessful, either because the authorization token was missing/invalid or you don't own the DID. | ||
402 | Transaction limit reached or upgrade required to proceed |
Get Credential
When a credential has been persisted on our systems, you can fetch the credential data by supplying a credential ID and the password used at issuance to encrypt the credential.
Parameters
Name | In | Type | Required | Description |
---|---|---|---|---|
did | path | string | true | The ID of the credential (as a full URI). |
password | query | string | true | The password given at issuance to encrypt the credential in storage |
Responses
Status | Meaning | Description | Schema |
---|---|---|---|
200 | The request was successful and will return the credential metadata and its JSON contents. | ||
404 | The requested credential was not found. | ||
402 | Transaction limit reached or upgrade required to proceed |
Delete Credential
A credential can have its metadata deleted, and if persisted the contents will also be deleted. Deleting a credential will remove any reference to it and its contents from our systems. This action cannot be undone. This action will not revoke or invalidate the credential in any way.
Parameters
Name | In | Type | Required | Description |
---|---|---|---|---|
did | path | string | true | The ID of the credential (as a full URL-encoded URI). |
Responses
Status | Meaning | Description | Schema |
---|---|---|---|
200 | The request was successful and credential will be deleted. | ||
404 | The request was unsuccessful, because the credential was not found. | ||
402 | Transaction limit reached or upgrade required to proceed |
Get Credentials Metadata
When you issue a credential with us, persistent or not, we will store certain metadata about the credential to make it easier for you to reference. You can pull a list of credential metadata using this route. To return the content of a persisted credential, you should use the GET /credentials/{id}
route
Parameters
Name | In | Type | Required | Description |
---|---|---|---|---|
offset | query | integer | false | How many items to offset by for pagination |
limit | query | integer | false | How many items to return at one time (max 64) |
Responses
Status | Meaning | Description | Schema |
---|---|---|---|
200 | The request was successful and will return the credential metadata and its JSON contents. |
Last updated