Issuer Guide Issuer

As an issuer you turn claims into signed, verifiable credentials. This guide covers designing schemas, issuing from the dashboard and the API, setting expiry, revoking, and the practices that keep your credentials trustworthy.

Designing schemas

A schema is the template behind every credential. Good schemas are small, clearly named, and stable. Under Schemas → New schema, name it and define each field.

Issuing in the dashboard

1. Open Credentials → Issue

   Start a new issuance.

2. Pick a schema and an issuing DID

   The DID's private key will sign the credential.

3. Enter field values and a holder

   Fill in the schema fields and select the End User who will hold it.

4. Set an optional expiry

   Choose a validity window if the claim should lapse.

5. Issue

   BlockID computes the canonical SHA-256 hash, signs it with RSA-SHA256, mints a verification token + QR, and writes a hash-chained ledger entry. The credential appears instantly in the holder's wallet.

Issuing via the API

Use the credentials:issue scope and POST /api/v1/credentials/issue.php. Minimal example:

curl -X POST https://example.com/api/v1/credentials/issue.php -H "Authorization: Bearer $TOKEN" -H "Content-Type: application/json" -d '{"did":"did:blockid:7c9e6679-7425-40de-944b-e07fc1f90ae7","schema_id":"sch_courses","holder_email":"alex@example.com","claims":{"fullName":"Alex Rivera","course":"Workplace Safety","grade":"Distinction","completedOn":"2026-06-25"},"expires_at":"2027-01-31"}'

A successful response returns the new credential, its ID, verification token, and signature. See the API Guide → issue for the full envelope and JavaScript/PHP examples.

Expiry

Expiry is optional but recommended for anything time-bound (memberships, certifications, passes). When the expiry date passes, verification returns EXPIRED automatically — you don't have to do anything. To extend, issue a fresh credential with a new window.

Revocation

Revoke when a credential should no longer be trusted before its natural expiry — an error, a status change, or a compromised holder device.

1. Open the credential

   Find it under Credentials.

2. Choose Revoke

   Confirm in the modal. BlockID records it in the revocation registry and writes a ledger entry.

3. Verify the effect

   From then on, verification returns REVOKED.

Via the API: credentials:revoke scope, POST /api/v1/credentials/revoke.php.

Best practices

• Verify the holder first. Make sure you're issuing to the right person and email before signing.
• Keep claims minimal. Issue only the fields a verifier actually needs — this minimizes unnecessary storage of sensitive identity data.
• Use expiry deliberately. Time-bound claims should expire on their own.
• Protect issuing DIDs. Limit who can issue against each DID; every signature is a statement of trust from your organization.
• Revoke quickly. The faster you revoke a bad credential, the smaller the window of misuse.
• Review the audit log. Confirm issuance and revocation events look right.