Skip to main content

Verifying credentials with TridentGold

A verifier is an organization that checks information someone presents from a digital credential. Your application asks for specific evidence, the person approves the request in the TridentGold app, and your application reads a verified result. Your application still makes its own service decision with that result.

Organizations that want to integrate should contact the TridentGold team. The pages in this section describe what the sandbox supports and how to call it.

What you ask for, and what you learn​

TridentGold answers requests written in DCQL, the Digital Credentials Query Language from OpenID for Verifiable Presentations. A DCQL query names the credential you want and the claims you want disclosed. Alongside it you can ask for predicates: conditions on a claim, such as "this date falls within the last six months", that are proved without revealing the value.

The wallet answers with a zero-knowledge proof. The verifier learns only what the request asked for:

  • the value of each claim you asked to have disclosed;
  • that each predicate you asked for is true, and nothing more about the underlying value;
  • optionally, a nullifier: a value that is the same each time the same holder answers a request with the same scope label, and that reveals nothing else about the holder.

Everything else in the credential stays in the wallet. What you can request lists the claims of the sandbox credential and what can be disclosed or proved about each.

From request to result​

  1. Your server creates a request. It sends a DCQL query, any predicates, an optional nullifier scope label and a purpose to the TridentGold verifier with the verifier SDK. The verifier checks the request against its allowlist, signs it, and returns wallet links, a request id and a secret result token. The SDK draws a QR code of the wallet link.
  2. The person opens the request in the TridentGold app. Your page shows the QR code, or a button that opens the app on the same phone. The app checks the signed request and shows who is asking, the purpose, and what will be disclosed or proved.
  3. The wallet proves. If the person approves, the app generates the proof on the phone and sends it to the verifier.
  4. The verifier checks the proof. It checks the proof, the issuer, the credential's current status, and that the response belongs to this request.
  5. Your server reads the result with the request id and result token, and your application decides what the result means for your service.

A person who does not hold a credential that satisfies every predicate cannot produce a proof. The wallet does not tell the verifier when a person declines either. In both cases the request simply expires, so an expired request means "no answer", never "no". Reading a result covers how to handle each outcome.

Signing in and checking credentials are separate​

Sign in with TridentGold establishes control of a holder account. Credential verification checks evidence an issuer attested. Signing in does not, by itself, establish a qualification, age or entitlement, and a verified credential result does not sign anyone in. If you arrived here looking for login, go to Sign in with TridentGold.

A nullifier lets you recognize that the same holder has answered a request with the same scope label before, for example to notice that the same holder has already registered for a programme. It is not an account identifier and does not connect to Sign in with TridentGold.

About this sandbox​

  • Every request goes through a shared TridentGold sandbox verifier. Your server calls the hosted sandbox verifier, which signs the request under its own name. People see the sandbox verifier's name in the app, not your organization's. No API key or registration is needed; the verifier is rate-limited and accepts only request shapes on its allowlist. You cannot run your own verifier or register your own verifier identity yet.
  • The data is synthetic. Sandbox credentials describe no real person. The synthetic sandbox police-certificate attestation is not an authoritative Police Certificate of Character.
  • The sandbox can be reset. A reset clears every credential issued in it, and testers then need a new one. Do not build anything that assumes a sandbox credential or a request survives a reset.

To try a request yourself you need the TridentGold app and a synthetic credential. Testers can get a credential themselves; see How to test. Test credentials from the sandbox's self-serve page have a decision_date 14 days before the day they were issued, so a decision_date range must include that date for them to answer.

The sandbox's wider operating facts are in What works today. Nothing in the sandbox has been reviewed.

Next​