Part 1. Setting up in the Workspace
All of this happens in the Truvera Workspace UI. Everything created here is what the code will refer to, and if any of it is wrong the code will fail in ways that look like code problems, so testing here will save time later.
1. Map the parties
Write down who issues, who holds, and who verifies the credentials. In this example the employer issues, the event platform verifies, the employee holds.
The ecosystem administrator, in this demo, is the same as the issuer, but they can be separate organisations.
For your use case. A party needs its own Truvera account when it holds its own API key and can participate in credential issuance/verification outside the ecosystem. Using sub-accounts is easier for organisations that are onboarded and managed by the ecosystem administrator, they still have separate API keys so tracking is not affected, but they do not have a separate Truvera login or billing relationship that would allow them to act without the ecosystem administrator.
2. Create the DIDs
Create a DID for the employer, and give it a name and logo. The name and logo are what a holder and a verifier see when they look at the credential, so they are worth setting even in a prototype.
First creating a did:cheqd DID for the issuer - employer.
Then, create the event platform subaccount and a DID inside it. Both DIDs need to exist before we can add them to the ecosystem.
For your use case. One DID per participating organisation. A holder's DID is generated by their wallet, you dont need to create them or log them in the Truvera workspace.
3. Create the ecosystem and add the participants
Create the ecosystem with the employer's DID as an administrator. Set a name, description, ecosystem URL, and a governance framework document. The governance framework is where the rules of the ecosystem are written down, and in a prototype a paragraph is enough.
Then add the employer as an issuer and invite the event platform as a participant.
A participant assigned a schema as a verifier schema becomes a verifier, one assigned it as an issuer schema becomes an issuer, and one assigned both is both. The schema comes next so participants either get their schemas at invitation time or have them assigned immediately after.
For your use case. Add one participant per organisation, and assign each of them only the schemas their role requires. A use case with several issuers is handled here too, they are participants in the same ecosystem with the same schema assigned as an issuer schema.
4. Design the schema
Schema depends highly on the use case you select. One schema determines the contents of one credential, so it is possible that you will want to add more than one schema to your prototype if it shows holders holding more than one kind of credential.
For the employee badge we will use these attributes: employer name, employee ID, full name, role or department, employment status, valid from, valid until (which is the credential expiration date).
Three rules to remember when designing a credential schema:
All data comes from one issuer. If part of the credential would come from a different source, that is a second credential.
All attributes share one level of assurance. Do not mix self-attested data with verified data in the same credential. The credential is trusted as a whole.
Group what shares a lifecycle, divide what does not. Employment status and role expire together, so they belong together. A professional qualification issued by a different body does not.
Build the schema in the workspace, every Truvera schema has a public URL. Keep the URL for the handoff file, and Claude Code can read the field names from it directly.
Schemas cannot be edited after creation. They can be copied and modified as a new version, but any credential already issued carries the old one, so it is worth getting the field names right now rather than discovering a typo after issuance.
Assign the schema to the ecosystem, to the employer as an issuer and to the event platform participant as a verifier schema.
For your use case. Run your own field list past the three rules above before you build it. Add as many schemas as are needed for your prototype
5. Create the verification template
For the verification you should follow the data minimization rule. The event platform does not need the whole employee badge. It needs to know that the holder works somewhere belonging to the Quotient ecosystem, and that the employment is current. Build the template to request only those fields.
For the badge, that means employer name and employment status, plus a constraint that the credential uses the badge schema. Leave out the name, the employee ID, and the role. The holder's wallet will only disclose what the template asks for.
This is the selective disclosure capability. The undisclosed fields are not merely omitted from what the verifier sees, they are cryptographically withheld while the signature over the whole credential still verifies.
Add the template to the ecosystem so the participating verifiers can use it.
For your use case. Start from what the verifier actually needs to make its decision. You can also combine attributes from multiple credentials in one verification template.
6. Check the setup with the mobile wallet
Before writing any code, prove the setup works.
Open the Truvera mobile wallet and copy its DID.
From the Workspace, issue a test badge to that DID as the subject ID, with revocation enabled.
The credential arrives in the wallet.
From the event platform account, create a proof request from the template in 4.6 and show the QR.
Scan it with the mobile wallet, present the credential, and confirm the verification succeeds.
Revoke the test badge from the Workspace, and run the verification again. It should now fail.
Making sure the schemas and verification templates work well together will save us time debugging it in the code in the later step.
7. Write the configuration file
Everything from here on refers back to these values. Create config.json in your project directory.
No API keys here. The two API keys and the EDV auth key go in .env that we set up in Part 3.
For your use case. Same file, your values. This is the contract between the Workspace and the code, and handing it over as a file saves us time adding this piece by piece when implementing the prototype in Part 3.
Last updated
Was this helpful?