Skip to main content

TridentGold overview

TridentGold is a citizen-held digital identity platform being developed for Barbados. Participating Barbados services integrate with TridentGold so people can use the same holder-controlled account across services, store credentials issued to them in the TridentGold app, and choose whether to disclose only the credential information a service requests. Sign in with TridentGold is intended to augment or replace parts of those services' existing digital account and authentication systems, such as email-and-password sign-in.

Identity proofing and authoritative source records remain outside TridentGold's scope and under the responsible agencies' control. The TridentGold wallet's credential capabilities form a digital layer above those records: agencies attest facts from their existing sources, holders keep the resulting credentials, and services request evidence from them.

The TridentGold system follows an issuer → holder → verifier model:

  1. An authorized issuer checks its authoritative records and issues a digital credential.
  2. The citizen, as holder, keeps the credential in the TridentGold app and decides when to use it.
  3. A verifier asks for authentication or specific evidence and validates the holder's response against trusted issuers and current status data.

This lets a service ask for only what it needs. Depending on the credential and request, the holder may disclose selected facts or prove a condition, such as meeting an age threshold, without sharing every field in the credential.

Authentication and credential-backed facts​

These are different assurances:

  • Sign in with TridentGold proves that the same holder-controlled account approved a sign-in. Pairwise identifiers are intended to give each user a distinct account identifier with each service, reducing linkability across services. A service may still request identifying information or credential evidence when needed.
  • Credential presentation supplies facts attested by an issuer, such as a licence class or eligibility result. The verifier must still check the issuer, proof, request binding, validity, and applicable status information.

An account can therefore authenticate without proving a civil identity, nationality, entitlement, or any other government-backed fact.

The designed model does not change. The next section states what this invited sandbox actually offers partners.

The current sandbox​

This sandbox is so you can integrate now: issue a test credential, check a proof, or add Sign in with TridentGold, using a live wallet and the published APIs. human.tech hosts the issuer and verifier so you do not have to stand those services up first.

It is an invited release using test data and test authorities. It does not issue an authoritative credential and does not make an identity or eligibility decision. The designed issuer, holder, and verifier model above is unchanged. This section is what the invited sandbox currently offers. What works today has the integration scope.

Who runs the machines​

human.tech hosts the sandbox issuer, status registry, and verifier on its infrastructure. The TypeScript credential SDK talks to those hosted services. It does not install an issuer or a proof-verification runtime in your environment.

Sign in with TridentGold is different: the wallet delivers the sign-in response to your site. human.tech is not in that login path.

A deployment where your organization runs the issuer or verifier with its own keys is the intended production model. It is not this sandbox.

What it means for you​

Relying parties. Sign in with TridentGold can be integrated on your site today with the RP SDK. The wallet signs the user in directly to you. You host request metadata and keys on your HTTPS origin, and testers approve the sign-in in the TestFlight app (same-device on iPhone is the path we support for a first integration). A successful sign-in proves control of that TridentGold account. It does not, by itself, prove name, eligibility, or any credential.

Issuers. human.tech operates the sandbox issuer. Through the sandbox's Tenant Gateway, a partner organization can define a synthetic credential schema and create invitations for testers from its own server with the issuer SDK, without operating an issuer or holding signing keys. See Issuance through the Tenant Gateway. You need an onboarding contact: GitHub access to the SDK is separate from the API key that issuance needs.

Verifiers. Verifiers can use the verifier SDK to request a zero-knowledge proof from a tester's TridentGold wallet with a DCQL query, and read the disclosed values, predicate results and an optional nullifier. See About this sandbox. The request and result types are the sandbox API, not a stable production contract.

How to get started​

  • Testers: ask your TridentGold contact for the TestFlight invitation and a one-time credential code. Follow How to test. You do not need GitHub or an SDK.
  • Relying parties: ask your contact for Read access to the private TridentGold repository, then install the signed SDK tarballs using SDK installation. Continue with Connecting your service. Testers still need the app.
  • Verifiers: install the verifier SDK the same way; no key or registration is needed. Continue with the verifier overview.
  • Issuers: same SDK install, plus a tenant API key from your contact. Continue with the issuer overview.

Standards and format boundaries​

The intended architecture adopts international standards and specifications where they fit, including OpenID4VCI for credential issuance, OpenID4VP with DCQL for credential presentation, SIOPv2 for holder authentication, ICAO 9303 for travel and identity documents, ISO/IEC 18013 for mobile driving licences, and X.509 for issuer trust. It defines TridentGold-specific profiles where additional requirements must be met.

ICAO 9303 travel documents and ISO/IEC 18013 mdoc credentials retain their native formats and trust models. The draft TridentGold ZKNC format is intended for domestic claims. Support for common standards does not by itself guarantee interoperability with every external wallet or verifier; that requires complete profiles, explicit mappings, and conformance testing.

What this documentation covers​

Start with The current sandbox for what is possible today, then How to test to receive and present a synthetic credential. Relying parties can follow Sign in with TridentGold; issuers can read Issuance through the Tenant Gateway; verifiers can follow the request and result guide.

Intended capabilities: secure agency issuance, selective credential presentation, national trust and status services, and integration with Barbados service-delivery workflows. These capabilities depend on the selected credential, environment, and approved deployment profile.

What works today records the current sandbox scope, SDK distribution status, and what is not available yet. The documented prerelease interfaces are provisional and do not define a production integration contract.