Issuing credentials with TridentGold
An issuer is an organization that provides a digital statement about someone: for example, that they hold a qualification, have a valid permit, or meet a particular requirement. That statement is called a credential. Government departments, educational institutions, and other organizations could issue credentials for facts they are responsible for confirming. These are examples of possible uses, not credential types available today.
TridentGold's issuance stack provides a way to deliver a digital credential to a person's TridentGold wallet and let them use it with participating services. Your organization continues to make the decision and maintain the underlying records.
From your records to a person's wallet
Your organization runs its own issuer service using TridentGold software, retaining control of issuance, signing keys, and credential decisions. Your existing systems connect to that service as part of your integration:
- Your existing staff and systems check the facts. Your organization identifies the applicant, checks its records, and decides whether to issue the qualification, permit, or other entitlement. These are your existing responsibilities; TridentGold does not perform those checks or make that decision.
- Your integration passes the approved information to your issuer service. You connect the relevant step in your application or case-management process to your issuer service. That connection sends the selected credential fields and a request to issue. Your existing system remains the source of record.
- Your issuer service prepares and issues the credential. It uses TridentGold software to handle the digital credential's creation, signing, and delivery to the wallet. Your application gives the recipient the resulting collection invitation through an agreed channel, such as your portal.
- The TridentGold wallet receives and protects it. The recipient accepts the offer in the app. The wallet and issuer service complete issuance, binding the credential to that wallet and storing it encrypted. Sending an invitation alone does not mean the credential has been collected.
For example, a training provider would still record and approve course completion in its own system. Its integration would ask its own issuer service, running TridentGold software, to issue the corresponding credential. The graduate would collect it in their TridentGold wallet and later choose whether to present it to an employer.
Who is responsible for what?
| Role | Responsibility |
|---|---|
| Your organization | Identify the applicant, decide eligibility, approve the information, and decide when a credential should be withdrawn or replaced. |
| Your issuer service | Run under your organization's control using TridentGold software to create and deliver credentials, protect signing keys, and publish authorized status changes. |
| The person holding the credential | Keep access to their wallet and choose whether to approve a request to use the credential. |
| The service checking it | Check the issuer, evidence, and status, then apply its own rules for access or eligibility. |
The credential does not replace your registry or case-management system. Changing a source record does not automatically update an already-issued credential; your integration needs a process for handling that change.
After a credential is issued
A status registry lets the wallet and verifying services check whether a credential remains active. Revocation means withdrawing that credential from further accepted use. It does not erase the copy in the person's wallet or, by itself, cancel the underlying permit, record, or entitlement.
Corrections normally involve issuing a replacement and deciding what happens to the old credential. Expiry dates, replacement rules, and who can authorize revocation are decisions your organization makes as part of the integration.
What you can explore now
The current sandbox demonstrates receiving, storing, presenting, and revoking a synthetic test credential. It uses a Police Certificate of Character-style example; it is not an official certificate or a connection to government records.
The planned ZKNC v1 release extends this into a documented sandbox integration for issuers and verifiers. It does not by itself authorize production use. Continue to Connecting your organization for current capabilities and the planned integration tools.