Skip to main content

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:
1

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.
2

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.
3

Verifier requests and validates the credential

An employer or opportunity provider creates a verification request specifying what they need to see. The youth’s wallet prompts them for consent. If they agree, the verifier receives cryptographic proof of the credential’s authenticity.

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:
AttributeShared?Why
Programme NameYesThe employer needs to know what she completed
Completion DateYesConfirms recency
Assessment ScoreNoThandi’s choice — not relevant to the job
Student IDNoInternal to Umuzi, not needed by employer
This is controlled by two mechanisms:
  • 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

The type 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:
Umuzi creates template
  → API returns type: "https://didx.co.za/vct/didx/web-dev-completion-v1"

Employment provider creates presentation template
  → references type: "https://didx.co.za/vct/didx/web-dev-completion-v1"
When an employment provider requests credentials of this type, the system knows exactly which credentials to match from the youth’s wallet. No direct integration between the issuer and verifier is required — the shared type is the trust bridge.
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
Presets ensure consistency across the ecosystem while giving partners the flexibility to capture what matters for their context.

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

StageWhat happens
Template createdAn issuing partner defines the credential structure (attributes, types, disclosure rules)
Credential issuedThe partner generates a specific credential with the youth’s data
Offer deliveredThe credential offer is sent to the youth’s wallet (via email or direct link)
Credential acceptedThe youth accepts the credential into their wallet (or it’s held in custody until they activate)
Presentation requestedA verifier asks the youth to share specific credentials
Youth consentsThe youth reviews the request and selectively shares attributes
Credential verifiedThe 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