Skip to main content

TridentGold app features

The TridentGold app is being built to let people sign in, receive digital credentials, and share only the information a service needs. Test builds are pre-release: available features and test data may change or be reset.

Accounts and sign-in​

You can create or access a holder-controlled account and approve supported Sign in with TridentGold requests. Device authentication helps protect local access. A sign-in confirms control of the same account; it does not by itself prove your legal name, civil identity, or eligibility for a service.

Credentials in your control​

The current iOS sandbox journey lets invited testers receive a synthetic credential, keep it encrypted in the wallet, present it to the hosted verifier, and refresh its status after issuer revocation. Follow How to test using the build assigned to you.

A credential is a digital statement from an issuer, not a new source of government data. The issuing agency continues to decide what its records mean and whether a credential should be issued, updated, or revoked.

Before a supported presentation, the app shows what a service is asking for so the holder can approve or cancel. Where the credential format supports it, the app can disclose selected fields or prove a condition instead of sharing the whole credential. The verifier receives the approved result and the evidence needed to validate it.

Mobile and web access​

TridentGold includes mobile and web experiences. The mobile app provides the strongest access to platform device protections where supported. The web app supports browser-based account and sign-in journeys, although available security capabilities depend on the browser, authenticator, and device.

Device security​

Account secrets are generated and used under holder control. On supported phones, device security and hardware-backed protection help guard account material at rest and require a local unlock for sensitive actions. These protections reduce risk but cannot make a compromised or unlocked device safe.

Holder-controlled recovery​

Holder-controlled recovery is designed around a recovery phrase or another approved, enrolled device, without giving the holder backend a plaintext copy of the account root. If every trusted recovery method is lost, a person may need to create a new account and ask issuers and services to reissue or migrate their records.

Authority-assisted, identity-bound recovery​

What happens if a person loses all access to their account—including every enrolled device and recovery phrase—and suspects that the account has been compromised?

TridentGold has a designed solution for this case: authority-assisted recovery for an identity-bound account. This is a future capability that Barbados could choose to deploy. Before it is enabled, Barbados should explicitly review and approve the mechanism, decide which credential classes are eligible, integrate the appropriate authoritative sources, and establish the recovery, privacy, audit, issuer, and service procedures that will govern it. Until those steps are complete, this recovery path is unavailable, and there is no mitigation for the account compromise case described above.

When an eligible identity credential is added, an approved process can create an opaque recovery binding between the authoritative identity record and the TridentGold account. A separate Identity Recovery Authority maintains that binding. It does not receive the account root, recovery phrase, or signing keys, and it cannot sign in as the holder.

If the account is later reported lost or compromised, the holder uses an independent identity-proofing and incident-reporting process. An authorized recovery operation can use the binding to quarantine the old account, blocking backend-mediated sync, backup, recovery, and device enrollment. The holder then creates a fresh account, while affected issuers and services separately decide how to suspend or reissue credentials, end sessions, and migrate their own records. The old account may ultimately be revoked or superseded under the approved lifecycle policy.

This mechanism is account containment and migration, not recovery of the old key or a global cryptographic kill switch. Quarantine cannot erase a copied account root or independently invalidate every credential or service session; issuers and services must act within their own systems as well.

To try the pre-release mobile app, see How to test.