> ## Documentation Index
> Fetch the complete documentation index at: https://docs.yoid.me/llms.txt
> Use this file to discover all available pages before exploring further.

# Verifying Credentials

> Request and verify youth credentials using the YoID platform.

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

| API              | Base URL                                 | Purpose                                            |
| ---------------- | ---------------------------------------- | -------------------------------------------------- |
| **Me Creds API** | `https://test.didxtech.com/me-creds/api` | Presentation templates, requests, and verification |

## Verification Workflow

<Steps>
  <Step title="Create a Presentation Template">
    Define what credential information you want to request — [Step 1](/api/verifiers/create-presentation-template)
  </Step>

  <Step title="Create a Presentation Request">
    Generate a specific verification request from the template — [Step 2](/api/verifiers/create-presentation-request)
  </Step>

  <Step title="Present the Request to the Youth">
    Display the request via QR code or link — [Step 3](/api/verifiers/present-request-to-user)
  </Step>

  <Step title="Verify Presentation">
    Receive and validate the youth's response — [Step 4](/api/verifiers/verify-presentation)
  </Step>
</Steps>

## Codes and Types

When an issuer creates a credential template, they provide a short **`code`** (e.g. `course-completion`). The API generates a **Verifiable Credential Type (VCT)** URI:

```
https://didx.co.za/vct/didx/course-completion
```

You reference this `type` URI in your presentation template. When a youth's wallet receives your request, it matches against credentials with this type.

<Note>
  You need the `type` URI from the issuing partner's credential template. Coordinate with learning and impact partners to obtain it.
</Note>

## 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 `course-completion` VCT 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.