Skip to main content

Holder

The holder layer consists of the TridentGold holder app across mobile and web and the TridentGold holder backend. Together they support account continuity and encrypted credential storage without making the backend the holder's identity authority.

Holder app​

The app is responsible for holder-controlled operations:

  • creating and using the self-custodial account root and derived keys;
  • enrolling a device and applying local device authentication;
  • receiving credentials through supported OID4VCI flows;
  • encrypting credential contents before holder-side synchronization;
  • producing pairwise, wallet-signed SIOPv2 authentication responses;
  • reviewing and consenting to OID4VP presentation requests; and
  • selectively presenting credential evidence when the format supports it.

Mobile devices can use hardware-backed protections where the platform and device support them. The web app uses browser and authenticator capabilities, which may provide a different custody assurance. Enrollment records must make those differences visible to recovery and security policy.

Holder backend​

The holder backend coordinates public account records, device enrollment, encrypted vault synchronization, encrypted backup material, challenges, policies, and non-PII operational metadata. It is not intended to receive the plaintext account root, recovery phrase, credential contents, pairwise subjects, or private signing keys.

SIOPv2 authentication is designed to be signed by the app and delivered to the relying party. The holder backend does not mint the holder's identity assertion and should not become a central log of which services a holder visits.

Account modes​

Every account starts as a bare account. It can authenticate to services and use holder-controlled recovery, but it has no authoritative link between the account and a civil-identity registry.

An identity-bound account (see Authority-assisted, identity-bound recovery) is a future deployment mode created only through an approved ceremony for a designated identity-bearing credential and jurisdiction. The binding would enable independent account containment and migration; it would not give the authority the account root. Until a binding is approved and completed, the account remains bare.

Authentication is not identity evidence​

A valid SIOPv2 response proves control of the account key for the requesting relying-party sector. It does not prove legal name, nationality, age, residency, licence status, benefit eligibility, or another civil fact. A service needing those facts must request and validate suitable issuer-backed credential evidence under an approved disclosure policy.

If the holder loses a device, supported holder-controlled methods can restore the existing root. If the root is suspected to be compromised, safe recovery may instead require a fresh account, credential reissuance, and relying-party account migration.