Connecting your organization

An issuer integration connects a decision in your existing system to a credential in someone's TridentGold wallet. For example, an approved application could trigger an offer to collect a credential.

This page explains the intended integration and current capabilities. Current describes the implemented sandbox. Planned for v1 describes work that is not yet a complete, supported integration.

How your systems connect

Your organization runs an issuer service: a server using TridentGold software to create credentials and coordinate delivery to the wallet. It operates under your control, preserving your autonomy over issuance and keys.

You connect your existing application to that service through its API or an SDK.

The starting point is one credential and one existing workflow. Agree which information comes from your records, when issuance should happen, and who can authorize it. The wallet handles receiving and protecting the credential; your application does not need to build its own wallet or proof generator.

Define the credential's fields

A schema defines the fields in a credential and their meaning: for example, a qualification name, awarding organization, and award date. It also determines which information can be requested or proved. Define each field clearly so issuers and verifiers interpret it consistently.

Current: one synthetic schema, TridentGold Sandbox PCoC Attestation v1. It contains an invented subject reference, a test result of “clear,” a decision date, and a reference number. It does not accept arbitrary credential types.

Planned for v1: published schema and integration guidance for the selected supported credentials, including field validation and version compatibility. Additional organizational credential types will need a defined schema and issuer registration; connecting an API does not make them supported automatically.

Credential status and revocation

Your organization decides when a credential should cease to be usable. The issuer service publishes that decision so wallets and verifiers can check it. Deleting a credential from a phone is not the same as revoking it.

Current: the sandbox operator performs revocation. A self-service issuer SDK workflow is not yet supported. After the operator confirms the update, refresh the wallet and create a new verifier request to check rejection. A request created before revocation keeps its original status allowance until it expires. An earlier accepted presentation also does not automatically end an existing session with a service.

Planned for v1: a supported way for your application to track issuance, retain a reference to the issued credential, and request lifecycle changes. Replacement and reissuance guidance will explain how to handle corrected records, interrupted delivery, and duplicate requests. The current sandbox does not guarantee one credential per person.

Current SDK: initiate sandbox issuance

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. The implemented backend sequence is:

1. Create createZkncMvpIssuerAdminClient() from @human.tech/tridentgold-zknc-mvp-client/admin, using the assigned issuer baseUrl and a server-only getAuthorization provider.
2. Call createInvitation({ claims }) with approved synthetic sandbox fields. The authorization provider supplies the complete invitation-service bearer value; it is not the protected revoke-admin identity.
3. Pass the returned invitation_code to openSession() on createZkncMvpIssuerClient() from the package's default entry point.
4. Return the wallet launch links and expiry to the initiating browser. The wallet performs issuance, proof generation, activation and storage.

The packaged examples/issuer.ts contains a callable beginIssuance() example and the supported synthetic claims shape. Do not log claims, invitation codes, or authorization. This is issuance initiation, not confirmation that a credential was issued or stored; no completion-tracking API is supplied.

createZkncMvpStatusClient() provides registry() and witness() data retrieval. Those calls do not independently authenticate the registry or establish that a credential is active. Trusted status validation remains in the wallet/verifier paths. The current SDK has no revoke() method.

Planned lifecycle API

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

credential = issue(approved_record, supported_schema)
check_status(credential.reference)
revoke(credential.reference)

The v1 lifecycle interface must add issuance tracking, issuer-retained references, authorized status changes, and defined retry/upgrade behavior. Sending a request, completing issuance, and the recipient storing the credential are distinct events; the integration needs to report them accurately.

Running your issuer service

TridentGold provides issuer software for organizations to run under their own control. Your organization is responsible for operating its service, protecting signing keys, managing access, and maintaining status publication and recovery.

Planned for v1 — not yet available as a complete supported distribution: SDKs, deployable container images, and documentation for setting up and operating your issuer service. The guides will cover configuration, monitoring, backups, recovery, and upgrades.

See Release and compatibility for the current app and SDK availability. The broader role of your organization is explained in the issuer overview.