What is a Verifiable Credential?
A verifiable credential is a digital equivalent of a paper certificate — but cryptographically signed, tamper-proof, and instantly verifiable by anyone the holder chooses to share it with. Think of it like this: when Thandi completes Umuzi’s web development programme, instead of receiving a PDF certificate she can forward to anyone (including someone who didn’t earn it), she receives a digitally signed credential stored in her wallet. Anyone she shares it with can verify in seconds that it was genuinely issued by Umuzi, hasn’t been altered, and belongs to her.The Three Roles
Every credential interaction involves three participants:Issuer creates and signs the credential
A learning partner, impact partner, or government body creates a credential from a template and issues it to a youth. The credential is cryptographically signed — proving who issued it and that it hasn’t been tampered with.
Holder receives and controls the credential
The youth receives the credential in their digital wallet. They decide who to share it with, when, and which specific attributes to reveal. This is selective disclosure — a core feature, not an afterthought.
Selective Disclosure
This is one of YoID’s most important capabilities — and it’s built into every credential by default. When Thandi shares her “Web Development Completion” credential with an employer, she doesn’t have to share everything on it. Each attribute in a credential can be individually disclosed or withheld:| Attribute | Shared? | Why |
|---|---|---|
| Programme Name | Yes | The employer needs to know what she completed |
| Completion Date | Yes | Confirms recency |
| Assessment Score | No | Thandi’s choice — not relevant to the job |
| Student ID | No | Internal to Umuzi, not needed by employer |
- At template level: Issuers mark certain attributes as
alwaysDisclosed(e.g. programme name) — these are always shared - At presentation time: Youth choose which remaining attributes to reveal
The Type Bridge
Thetype field is how the ecosystem stays connected without partners needing direct relationships.
When Umuzi creates a credential template for “Web Development Completion”, the API returns a type URI — a unique identifier for that credential type. This URI is what connects issuers to verifiers:
The type URI is generated automatically when a credential template is created. Share it with verifying partners who need to request credentials of that type.
Credential Format: SD-JWT-VC
All credentials in the YoID ecosystem use the SD-JWT-VC format (Selective Disclosure JSON Web Token — Verifiable Credential). This is an open standard that enables:- Selective disclosure — youth share only the attributes they choose
- Cryptographic verification — verifiers can confirm authenticity without contacting the issuer
- Cross-wallet compatibility — credentials work across different wallet implementations
- Compact size — efficient for mobile-first environments
Skills via Open Badges v3
Coming soon. YoID is adding support for Open Badges v3, enabling skills to be embedded directly within verifiable credentials. This means verification will happen at a skill level — not just at the credential level. A youth won’t just prove they completed a programme; they’ll prove they hold specific skills (e.g. “JavaScript”, “Financial Literacy”) as individually verifiable claims. This unlocks granular skill-based matching between youth and opportunities across the ecosystem.
Ecosystem Presets
YoID provides ecosystem presets — standardised credential structures that define common credential types across the YOMA network. Partners can:- Create a template from a preset — use a pre-defined structure as-is for quick onboarding
- Customise based on a preset — start from a YoID preset and add or modify attributes to fit their specific programme
Async Credential Pipeline
A critical feature for partners onboarding youth at scale: credentials can be issued before the youth has activated their wallet. When a partner issues a credential, it doesn’t matter if the youth hasn’t downloaded the wallet app yet. The credential is held in a custodial state. When they eventually sign in, the credential is already there — waiting to be accepted. This async pipeline means partners can integrate and issue credentials without worrying about youth wallet activation timing.Credential Lifecycle
| Stage | What happens |
|---|---|
| Template created | An issuing partner defines the credential structure (attributes, types, disclosure rules) |
| Credential issued | The partner generates a specific credential with the youth’s data |
| Offer delivered | The credential offer is sent to the youth’s wallet (via email or direct link) |
| Credential accepted | The youth accepts the credential into their wallet (or it’s held in custody until they activate) |
| Presentation requested | A verifier asks the youth to share specific credentials |
| Youth consents | The youth reviews the request and selectively shares attributes |
| Credential verified | The verifier receives cryptographic proof of authenticity |
Next Steps
Start Integrating
Ready to build? Start with the API introduction
Issuer Workflow
See how learning and impact partners issue credentials

