Skip to main content

Verifying credentials with TridentGold

A verifier is an organization that checks information someone presents from a digital credential. For example, an employer could check a qualification issued by a training provider, or a service could check whether an applicant meets an age requirement. These are possible uses; available checks depend on the supported credential types and features.

TridentGold provides verifier software that you integrate into systems you operate. Your organization chooses which evidence to require and which issuers to trust. Your application uses the verified result to make its own decision.

From your service's request to a verified result​

TridentGold provides the verifier software and SDKs for your service, along with the mobile wallet app for the person presenting a credential. Your existing application connects to these components:

  1. Your application determines what evidence is needed. Your existing service rules identify the information or conditions required for the task, such as a particular qualification. You configure the supported request and acceptable issuers.
  2. Your verifier service creates the request. It uses TridentGold software to produce a signed, expiring request. Your application gives the person a link or QR code to open it in their wallet.
  3. The TridentGold wallet asks for consent. It checks the request and shows who is asking, the purpose, and what will be disclosed or proved. If the person approves, the wallet generates a proof and sends it to your verifier.
  4. TridentGold's verifier software checks the evidence. Running in your verifier service, it checks the proof, your configured issuer trust rules, credential validity and status, and the response's connection to this particular request. It returns the result to your application.
  5. Your application makes the service decision. It uses the verified result alongside its other requirements. TridentGold does not decide whether to approve an application, offer employment, or grant an entitlement.

In the qualification example, your verifier checks the evidence from the training provider. Your recruitment system still decides whether that qualification satisfies the requirements for a role.

Choose the evidence and issuers you accept​

An authentic credential is useful only if its issuer is a source you accept for that information. Define which issuers you trust for each credential type and which fields or conditions your service needs to check. Trusting an issuer for one credential type does not require accepting everything it issues.

A presentation is the evidence the holder provides in response to your request. Depending on the credential and supported request, it can disclose a field or prove a condition without disclosing the underlying value. For example, proving an age threshold need not reveal the date of birth. Request only the information needed for your decision.

Authentication and credential evidence​

Sign in with TridentGold establishes control of a holder account. Credential verification checks evidence supplied by an issuer. Signing in does not, by itself, establish a qualification, age, or entitlement.

If your application needs both, connect each result to the appropriate user session. A successful credential presentation should not be treated as a returning-account identifier unless the integration explicitly provides one.

Current scope​

The current sandbox verifies a configured request against a synthetic test credential. It demonstrates proof verification and credential status checks; it does not establish real qualifications or eligibility. The result available to the application currently contains acceptance or rejection and a coarse reason, rather than disclosed field values.

The planned ZKNC v1 release extends the supported requests and integration tools for a sandbox pilot. See Connecting your service for current capabilities and the planned interfaces.