Skip to main content

Sign in with TridentGold

A relying party is a service that lets someone sign in with their TridentGold account. That is account authentication. It is not the same role as a verifier, which checks issuer-backed credential evidence.

Sign in with TridentGold is designed so the wallet is the identity provider. The holder approves a sign-in in the TridentGold app; the wallet signs the assertion and delivers it directly to your service. No TridentGold-operated service sits in that login path, so TridentGold does not learn which service the holder signed into.

What this sandbox makes available for a first integration is described in The current sandbox. This page is the intended relying-party model. The sign-in guide covers the current SDK.

From your application to an authenticated session​

  1. Your backend creates a signed sign-in request. You host the request metadata and keys on your HTTPS origin. The SDK persists the pending transaction before you launch the wallet.
  2. The holder opens the request in the TridentGold app. Same-device sign-in launches the installed wallet. Cross-device QR is a separate path with its own risk choices.
  3. The wallet checks the request and asks for consent. It validates that the request metadata and keys come from your origin. The consent screen shows that origin. A registry of attested organization names is not part of this sandbox.
  4. The wallet signs the response and sends it to you. Pairwise identifiers are intended to give each holder a distinct account identifier with each service. Your backend verifies the callback and creates your application session.

Your application still decides what that session is allowed to do.

Authentication is not credential evidence​

A successful sign-in proves that the same holder-controlled account approved the request. It does not prove legal name, nationality, age, a licence, eligibility, or any other issuer-backed fact.

If your service also needs credential evidence, that is a verifier integration. There is no single SDK operation that signs the user in and verifies a credential. Connect each result to your own session if you need both.

Current scope​

Invited relying parties can integrate same-device sign-in against the TestFlight iOS app using the published RP SDK. Testers must have that app.

See Connecting your service for the current request and callback APIs and What works today for the integration scope.