Skip to main content

​
Overview

As an employer or opportunity provider, you use the YoID platform to request specific credentials from youth and verify their authenticity. Instead of weeks of manual document checking, you get instant cryptographic verification and richer candidate profiles than any PDF certificate could provide. An employment provider doesn’t think “I’m a verifier” — they think “I need to confirm this candidate actually completed that programme before I place them.” That’s exactly what this workflow does.

​
What Happens on the Youth’s Side

When you send a verification request:
  1. The youth’s wallet displays exactly what you’re asking for and who’s asking
  2. The youth sees which credentials in their wallet match your request
  3. They choose which credential to present (if they have multiple matches)
  4. They can selectively disclose only specific attributes — sharing their programme name without revealing their assessment score
  5. They can decline the request entirely
Youth agency is the core principle. Every verification request is a consent prompt, not a data extraction.

​
API Used

The entire verification workflow uses a single API:
APIBase URLPurpose
Me Creds APIhttps://test.didxtech.com/me-creds/apiPresentation templates, requests, and verification

​
Verification Workflow

1

Create a Presentation Template

Define what credential information you want to request — Step 1
2

Create a Presentation Request

Generate a specific verification request from the template — Step 2
3

Present the Request to the Youth

Display the request via QR code or link — Step 3
4

Verify Presentation

Receive and validate the youth’s response — Step 4

​
The Type Bridge

The type field connects you to issuers without needing a direct relationship. When Umuzi created their “Web Development Completion” credential template, the API generated a type URI like: 
https://didx.co.za/vct/didx/web-dev-completion-v1
You reference this exact URI in your presentation template. When a youth’s wallet receives your request, it matches against credentials with this type. This is how trust flows across the ecosystem — shared types, not shared databases.
You need the type URI from the issuing partner’s credential template. Coordinate with learning and impact partners to obtain the type URIs for credentials you want to verify.

​
Example: Employment Provider Verifies a Candidate

An employment provider (e.g. JobJack) is processing applications for junior developer roles. They want to verify that candidates have completed the Umuzi web development programme:
  1. The employment provider creates a presentation template referencing the WebDevCompletion type URI
  2. When Thandi applies, they generate a presentation request
  3. Thandi scans a QR code with her wallet, sees what’s being requested
  4. She shares her completion credential — selectively disclosing the programme name and completion date, withholding her assessment score
  5. The employment provider receives cryptographic proof that the credential is genuine, issued by Umuzi, and unaltered
Total verification time: seconds, not weeks.

​
Privacy by Design

The verification flow gives youth complete control over what they share:
  • Select credentials — if a youth has multiple matching credentials, they choose which to present
  • Selective disclosure — share only the attributes the verifier needs, nothing more
  • Decline entirely — youth can reject any verification request without consequence
No personal information is stored by the verifier. You receive cryptographic proof, not a copy of the youth’s data.