Documentation Index
Fetch the complete documentation index at: https://docs.didx.co.za/llms.txt
Use this file to discover all available pages before exploring further.
The three roles
| Role | Who it is | What they do |
|---|---|---|
| Issuer | A university, employer, government department, or platform that creates credentials | Signs credentials and offers them to a holder |
| Holder | The user, via their wallet | Holds credentials and consents to share them with verifiers |
| Verifier | A bank, employer, marketplace, or platform that consumes credentials | Requests credentials and validates them |
A single organisation can play multiple roles over time. A university issues student cards (issuer). A bank verifies them when the student opens an account (verifier). The student holds them in their wallet throughout (holder). When designing your integration, identify which roles you will play, because that determines which of the three APIs you’ll use most.
How information flows
A typical flow involves two of the three roles at a time. Issuance is between an issuer and a holder. Verification is between a holder and a verifier. The trust relationship between issuer and verifier is established cryptographically, not through a live API call between them.
- The issuer is not contacted at verification time. The verifier confirms the credential cryptographically.
- The verifier defines what to ask for. The holder decides whether to share and, if multiple credentials satisfy the request, which credential to present.
- Trust flows through cryptographic signatures and a list of trusted issuers, not through live API lookups between companies.
Which role decides what
A common question: “who controls the data?” Each role owns a different part of the decision.| Decision | Owned by |
|---|---|
| What attributes a credential contains | Issuer (via the credential template) |
| Which attributes are always visible vs. optional (SD-JWT only) | Issuer (via alwaysDisclosed) |
| Whether to accept or reject an offered credential | Holder |
| Whether to share a credential in response to a presentation request, and which credential to present when multiple satisfy the request | Holder |
| What a presentation request asks for | Verifier |
| Which issuers to trust | Verifier, by linking trusted entities to credentials within a presentation template |
| Whether a presented credential passes verification | Verifier, by cryptographic rule |