Issuance through the Tenant Gateway

An issuer is an organization that provides a digital statement about someone: for example, that they completed a course or hold a permit. That statement is a credential. In this sandbox a partner organization can define a synthetic credential schema and deliver credentials under it to a tester's TridentGold app, without running an issuer or holding signing keys.

Organizations that want to try issuance should contact the TridentGold team. The pages in this section describe what the sandbox supports and how to call it.

Status. The Tenant Gateway described here is running. You need an API key from your contact before you can call it. What works today has the current state.

Tenants and the Tenant Gateway

A tenant is a partner organization with access to the sandbox's Tenant Gateway. The gateway is the service your server calls.

What the credential is called, which fields it has and what values go in them are yours to decide. Who signs it, and what that means, is in About this sandbox.

Get an API key

Contact the TridentGold team. Your onboarding contact:

• registers your organization as a tenant, with a short name for it (the tenant slug, for example acme-training) chosen from your organization's name. The slug is public: it is part of every schema identifier, sandbox.tridentgold.t.<slug>.<name>, which the signed trust list, the verifier's policy and each credential's schema carry. Tell your contact if your organization should not be named in the slug;
• gives you a tenant API key once, over a secure channel. It starts tgk_. Keep it in your server's secret store, never in a browser, a repository or a log;
• gives you the gateway's URL and access to the TypeScript SDK bundle.

If a key is exposed, ask your contact to revoke it and issue another.

From schema to wallet

1. You define a schema. A schema names the credential and its four fields, their types and how the TridentGold app displays them. Your server submits it with the issuer SDK. See Defining a schema.
2. The TridentGold team approves and publishes it. A person on the team reviews how the app will display it and approves it. The team then publishes it in the sandbox's signed trust list, which is how the sandbox issuer, the verifier and the app learn about it.
3. Your server creates an invitation. For each tester, your server sends the credential's values (synthetic ones only) and gets back a one-time invitation code. See Creating invitations.
4. The tester collects the credential. The tester types the code into the TridentGold app. The app and the sandbox issuer complete issuance, bind the credential to that app and store it encrypted on the phone.
5. You track the invitation from available to activated, without seeing anything the tester does in the app.

A verifier can then ask the tester's app for proof about the credential; see Check a credential under your schema.

Who does what

Party	In this sandbox
Your organization	Defines the schema, decides who gets an invitation and with which synthetic values, and keeps its API key secret.
Tenant Gateway	Checks your key, completes and checks your schema, keeps each organization's schemas and invitations apart, and applies limits.
TridentGold team	Approves each schema by hand and publishes it.
TridentGold ZKNC Sandbox Issuer	Issues the credential to the tester's app and records its status.
The tester	Chooses whether to collect the credential and whether to answer a verifier's request.

About this sandbox

• Every credential is signed by the shared TridentGold ZKNC Sandbox Issuer. No organization signs its own credentials here. The app shows the sandbox issuer as the issuer, and a Sandbox badge on every partner-defined credential. Such a credential is described as "a synthetic sandbox credential defined by your organization and issued by the TridentGold ZKNC Sandbox Issuer".
• Which organization a schema belongs to is enforced, not proved. The gateway keeps each tenant to its own schemas, and the TridentGold team approves each schema by hand. Nothing in a credential proves cryptographically which organization defined it: a holder or verifier relies on human.tech, as the sandbox operator, for that. Proof per organization would need each organization to hold its own admitted issuer key, which this sandbox deliberately avoids.
• Data must be synthetic. The gateway and issuer check the values they can, such as the SANDBOX- prefix on text. Those checks cannot prove that data is fake. Never enter real personal data, including names, dates of birth, document numbers or anything else about a real person.
• The sandbox can be reset. A reset clears the status of every credential in it, and testers then need new ones. If the TridentGold team withdraws a schema, credentials already collected under it show as unavailable in the app and cannot be presented. Do not build anything that assumes a sandbox credential survives.
• Testers need a recent app build. Receiving a credential for your schema needs a TridentGold app build that includes the version 2 trust bundle and schema-driven credential display. An earlier build cannot receive it: the build has no copy of your schema, so collection fails. Use TestFlight build 18 or later.

No dependency or security review of the sandbox has been performed. The sandbox's wider operating facts are in What works today.

Next

• Defining a schema: the template, display fields, submission and approval.
• Creating invitations: the issuer SDK, a Next.js route handler, invitation status, errors, and checking a credential with the verifier SDK.