Security
TridentGold is designed to keep account and credential use under holder control while letting issuers and verifiers enforce their own trust and lifecycle decisions.
Custody and encrypted storage
The app generates account key material for the holder. The ordinary TridentGold holder backend is designed to store public material, encrypted records, and non-sensitive account metadata—not plaintext account roots, recovery phrases, credential contents, or signing keys. Credential storage is encrypted with holder-controlled keys.
On supported devices, hardware-backed storage and local device authentication protect account material at rest. Support and assurance vary by platform, device, authenticator, and enrollment state; hardware protection is not a claim that keys can never be copied from a compromised runtime.
Data minimization
Pairwise identifiers are intended to give different relying-party sectors different stable account identifiers. Selective disclosure and zero-knowledge-capable credentials can reduce the facts revealed in a presentation. Neither control replaces consent, purpose limitation, retention rules, or sound authorization at the relying party.
Operational logs and telemetry must contain no PII, credentials, secrets, tokens, recovery material, private keys, or presentation payloads. Errors should be actionable through safe event names and correlation data rather than sensitive request contents.
Trust and credential status
A verifier must validate the proof and its binding to the current request, accept only issuers authorized by the applicable trust framework, and apply the credential format's validity and status rules. Issuers protect credential signing keys and remain responsible for suspension, revocation, supersession, and reissuance decisions.
Three separate recovery and containment planes
- Account containment: the holder backend can deny sync, backup, device enrollment, recovery, and other backend-mediated operations for a contained account.
- Credential lifecycle: each issuer can change the status of its digital credential instances. That is separate from the status of the TridentGold account and from the underlying document or entitlement.
- Relying-party recovery: each service controls its own sessions and local account. It must decide how to end sessions, disable an old pairwise subject, and map an authorized holder to a new local account or subject.
No single cryptographic global kill switch exists for a copied account root or an offline credential. Backend quarantine cannot erase a copied root or prevent every direct, locally authorized signature. Credential status cannot always be checked while offline. Effective incident response therefore requires the holder, relevant issuers, and relying parties to act in their own enforcement planes.
Identity-bound recovery
See Authority-assisted, identity-bound recovery.
Ordinary recovery remains holder controlled. A future identity-bound account mode is intended to add an independently authorized path to identify, quarantine, revoke, or supersede a compromised account without escrowing the account root. It is not a way for an authority to recover the old key or sign as the holder.
This capability requires credential-specific approval, authoritative-source integration, privacy review, operating procedures, and relying-party and issuer coordination. It must remain disabled where those conditions have not been met.