Connecting your service

Your application connects to a verifier service running TridentGold software under your organization's control. The service creates presentation requests and checks the wallet's proofs. Your application controls the user experience and the decision that follows verification.

Current describes the implemented sandbox. Planned for v1 describes work that is not yet a complete, supported integration. The hosted demo is an example deployment; it is not a required intermediary for organizational verification.

Define the evidence you need

Choose the credential types and issuers your service accepts, then define the fields or conditions needed for your decision. A request could ask to disclose a qualification name or prove that an age is above a threshold. These are different requests: one returns information, while the other establishes a condition without revealing the underlying value.

Use the credential's schema to identify the fields and their meaning. Your request must be supported by both the credential and the verifier software.

Current: request creation uses one configured sandbox profile. The API does not accept arbitrary field selections or queries.

Planned for v1: documented request options for the selected supported credentials, including disclosure and condition checks, with working examples and compatibility requirements. This does not imply support for every credential format or wallet.

Connect the request to your application

Create the request from your backend and associate it with the transaction that needs verification. Give the frontend the wallet launch link and expiry; keep request authorization and result-access tokens on the server.

The wallet checks the verifier's identity before asking for consent. Your verifier's identity, request-signing key, and response endpoint therefore need to be registered in the wallet's trusted configuration. The current sandbox uses configured records; automatic onboarding of new verifiers is not available.

A request belongs to one transaction and expires. Start a new request for a new attempt, and stop accepting results when your application has cancelled or expired the transaction. Receive the proof at your verifier service; your application retrieves the authenticated result.

Use the verified result

Result	What your application should do
Pending	Wait within the request's lifetime. No evidence has been accepted yet.
Accepted	Apply the verified result to the matching live transaction and evaluate your service rules.
Rejected	Do not treat the requested evidence as established.
Unavailable or failed	Leave the transaction unverified. Retry when appropriate without treating an error as acceptance.

A successful HTTP response alone does not establish that a proof was accepted. Use the verification outcome from your server's authenticated result request.

Current: the application-facing result contains acceptance or rejection and a coarse reason. It does not return disclosed attributes or a stable account identifier. Applications that need those values require an extended result interface; they cannot obtain them from the current result endpoint.

Planned for v1: a documented result contract for the supported requests, including verified outputs and stable error handling. Request and result types will be published together so you can determine exactly what a successful check establishes. Account sign-in remains a separate integration.

Credential status and revocation

A credential may have been revoked since it was issued. The verifier checks status as part of checking the proof, using the status information allowed by the request. If it cannot authenticate the required status information, your application must leave the transaction unverified.

Current: new requests use the authenticated current status version. A request created before a revocation retains its original status allowance until expiry. To check a newly published revocation, create a fresh request.

Verification is a decision at a particular time. Revocation does not automatically end a session or withdraw access already granted by your application; you define when further checks are needed. See the issuer status guidance for the issuer's role.

Current SDK: request sandbox verification

Current: the package implementation is ready at 0.1.0-mvp.2; distribution is pending. Follow SDK installation once your onboarding contact supplies an approved release.

Create createZkncMvpVerifierServerClient() from @human.tech/tridentgold-zknc-mvp-client/verifier-server on your backend. Supply the assigned verifier baseUrl and getAuthorization, which obtains the full server-held verifier RP bearer for each request creation.

createPresentationRequest() returns session, result_uri, and result_token. Save the session ID, token and expiry in a server transaction bound to the initiating browser. Give the browser only the launch links and expiry. Poll with presentationResult(sessionId, resultToken), which uses that request-specific token rather than the RP request-creation authorization.

The returned fields are:

type PresentationResult =
  | { state: "pending" }
  | { state: "unavailable" }
  | { state: "complete"; accepted: boolean; reason: string };

The packaged examples/verifier.ts provides initiation/polling helpers with timeout and local cancellation/expiry handling. Load its server state only after checking transaction ownership, and recheck ownership, cancellation and expiry atomically before applying a result. These local states do not add API fields.

The holder-facing verify() submits a proof to the verifier service; it does not verify proofs locally in TypeScript. Wallet proofs go directly to the verifier's Cloud Run endpoint, not through a Vercel application proxy.

Current SDK: account sign-in

@human.tech/tridentgold-siop-rp exports createTridentGoldSiopRpClient(). Its backend API supports initiate(), processCallback(), and readTerminal(); the packaged examples/sign-in.ts shows their use with injected configuration, a request signer, and transaction storage. Persist the initiating-browser binding on the server and validate the wallet callback before creating an application login session.

This is SIOP account authentication. It does not verify a ZKNC credential or automatically bind a separate credential presentation to the authenticated account. There is no single exported signin() that performs both operations.

Planned request and result API

Planned for v1 — not implemented as shown. This pseudocode illustrates the intended tasks, not actual SDK method names:

request = create_request(required_evidence, trusted_issuers)
show_wallet_link(request)
result = await_verified_result(request.reference)

The v1 interface must define supported request selection, verified outputs, stable error/versioning behavior and interoperability. The fixed-profile current request/result APIs above do not establish those broader contracts.

Running your verifier service

You operate the verifier software and configure the issuers, credential types, and status sources it accepts. Protect request-signing keys and service access, and maintain the service state needed to process requests and results reliably.

Planned for v1 — not yet available as a complete supported distribution: verifier SDKs, deployable container images with the matching proof runtime, and documentation for configuration, monitoring, recovery, and upgrades. Installing an HTTP client alone does not install the proof-verification service or register its identity with wallets.

See Release and compatibility for current availability and the verifier overview for the roles in a verification flow.