> For the complete documentation index, see [llms.txt](https://docs.truvera.io/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.truvera.io/solutions/building-a-digital-identity-ecosystem-prototype-with-ai-tools/part-1.-setting-up-in-the-workspace.md). # 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. {% embed url="" %} ### 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](/truvera-workspace/create-an-organization-profile-did.md) 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 ](/truvera-workspace/team-management/sub-accounts.md)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](/truvera-workspace/ecosystem-tools.md) 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.
Example governance framework Quotient Employment Credential Ecosystem Governance framework Version 1.0 **1. Purpose** This ecosystem enables employers to issue verifiable employee badges, and allows third-party services to confirm that a person is currently employed without contacting the employer or receiving more information than they need. Quotient convenes this ecosystem, admits participants, assigns their roles, and may remove a participant that does not meet the requirements below. **2. Participants** Issuers are organisations that employ the people they issue to. An issuer may only issue an employee badge to a person it currently employs, and must have verified that person's identity and employment through its own onboarding. Holders are the employees. They hold their badge in a wallet they control. Verifiers are organisations that need to confirm employment as a condition of providing a service. A verifier may only request the attributes it needs for the decision in front of it, and must not retain them for longer than that decision requires. Roles follow from the schemas assigned to a participant. **3. Credentials** Issuers must use the Employee Badge schema published in this ecosystem, issue with revocation enabled, and set a validity period of no more than twelve months. An issuer must revoke a badge without undue delay when the employment ends or when it learns the badge was issued in error. Verifiers rely on revocation status at the time of presentation and are not notified. Issuers do not learn where or when a holder presents their badge.
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](/truvera-workspace/create-a-schema.md), 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](/truvera-workspace/verify-credentials.md) 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. 1. Open the Truvera mobile wallet and copy its DID. 2. From the Workspace, issue a test badge to that DID as the subject ID, with revocation enabled. 3. The credential arrives in the wallet. 4. From the event platform account, create a proof request from the template in 4.6 and show the QR. 5. Scan it with the mobile wallet, present the credential, and confirm the verification succeeds. 6. 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. ```json "ecosystem": "Quotient Employment Credential Ecosystem", "issuer": { "name": "Quotient", "did": "did:cheqd:testnet:z6MkfWt2wJ8xR4nQvB7hL3pYcE9dT5sN1aK" }, "verifier": { "name": "Event Platform", "did": "did:cheqd:testnet:z6MkqR8vN3hT7wY2bL5xJ9cF4dP6sM1aG" }, "schema": { "id": "3f9a2c81-6d47-4e12-b58a-91c0e7d34b26", "url": "https://schema.truvera.io/3f9a2c81-6d47-4e12-b58a-91c0e7d34b26.json" }, "proofTemplate": { "id": "7b41e0d9-2f83-4a56-9c17-e5d82b4f06a3", "name": "Employment check" } } ``` 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. --- # Agent Instructions This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com. ## Querying This Documentation If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question. Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter: ``` GET https://docs.truvera.io/solutions/building-a-digital-identity-ecosystem-prototype-with-ai-tools/part-1.-setting-up-in-the-workspace.md?ask=&goal= ``` `ask` is the immediate question: it should be specific, self-contained, and written in natural language. `goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal. The response will contain a direct answer to the question and relevant excerpts and sources from the documentation. Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.