Skip to main content
A verifiable credential packages a Dataerai DID into a portable JSON document that another person or system can verify. Use public credentials for citable public identities. Use sealed credential shares when a credential should be opened only by a specific party with a shared key.

​
When to use a credential

A credential is a self-contained proof you can hand to someone outside Dataerai. Reach for one when you want to:
  • give an external reviewer or collaborator portable proof that a record is yours and unchanged, without inviting them into the app;
  • attach a verifiable claim about a DID to a report, submission, or pipeline that travels independently of the record;
  • share that proof with one specific party — a person, organization, or group — using a sealed credential share that only they can open.
Credentials are available through the REST API (and any SDK or script that calls it) — there is no dedicated web UI for issuing, sharing, or verifying them yet. Every example below is a curl request you can adapt.
Replace $DATAERAI_SERVER with your Dataerai host in the examples below. $DATAERAI_TOKEN is an OAuth2 access token — see Authentication for how to get one. The verify and public-fetch endpoints need no token.

​
Before you issue a public credential

You can issue a credential only for a DID that is already published. Private or gated DIDs cannot receive public credentials. The person issuing the credential must own the record.

​
Issue a public credential

The response includes the signed credential JSON, id as the UUID path segment, credential_id as the full credential URL, and a status URL inside the credential JSON. The credential contains the DID, the public identity commitment, the latest identity sequence, and the Dataerai issuer. It does not include private record metadata. You can add an optional future expires_at timestamp when you want the credential to stop verifying after a specific time.

​
Share a credential

Share either the credential JSON or the returned credential_id URL:
You can also fetch it from the API path with the returned id value:
Anyone can fetch a credential by URL and check its status. They do not need a Dataerai account.

​
Issue a sealed credential share

Use a sealed credential share when the credential should be readable only by an intended party. The recipient can be a user, linked person, organization, or group. The signed credential is encrypted with the shared key; the shared key is not stored by Dataerai. Shared keys must be at least 24 characters.
recipient_type can be user, person, organization, or group. Sealed credential responses include a share id, the credential URL, recipient metadata, and status. They do not include the signed credential body.

​
Open a sealed credential share

The caller must belong to the recipient party and provide the same shared key:
A successful response returns the signed credential and a verification result. Wrong-party callers get 404. Intended-party callers with the wrong key get 403. Revoked shares return 410. Public credential fetch and status endpoints return 404 for sealed credentials:

​
Verify a credential

To verify a credential JSON document:
To verify a credential already stored by your Dataerai server:
A valid credential means the signature is intact, the issuer matches your Dataerai server, the signing key is trusted, the credential status is active, and the DID commitment still appears in the signed identity log. Opened sealed credentials verify against the stored credential digest, so Dataerai does not need to store the sealed credential body in plaintext.

​
Check status

The status endpoint reports whether the credential is active or revoked.

​
Revoke a credential

Revoking a credential does not delete it. The credential remains fetchable so existing citations do not disappear, but verification reports it as invalid.

​
Revoke a sealed share

Revoking a sealed share does two things at once. The recipient party can no longer open it (the open endpoint returns 410 Gone), and — because each sealed share has its own one-to-one credential — the underlying credential is revoked too. So a copy the recipient already opened (or passed on) immediately stops verifying as valid. Revocation is permanent; a credential cannot be un-revoked. Only the credential owner, an admin, or the user who created the share can revoke it. The recipient can open the share but cannot revoke it.
Verifiable credentials use the same Dataerai DID and key trust model as identity verification. Sealed shares add party membership plus shared-key decryption. Neither flow requires a blockchain wallet or any on-chain transaction.

​
Next steps

Publish & cite

Make a DID public before issuing a credential.

Resolve & verify

Verify a DID directly through the public identity endpoints.