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

# Roles

> didx:me is built around three roles: issuer, holder, verifier. Here's what each one does and how information moves between them.

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

<Note>
  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.
</Note>

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

<Frame>
  <img src="https://mintcdn.com/didx/5ow3MRkvKVSTJoa8/images/concepts/ssi-trust-diamond.svg?fit=max&auto=format&n=5ow3MRkvKVSTJoa8&q=85&s=c8bbc7c2c9589a91faf9282bd270160e" alt="The trust diamond: issuer, holder, verifier connected around a Verifiable Data Registry." width="800" height="520" data-path="images/concepts/ssi-trust-diamond.svg" />
</Frame>

Walking through the steps:

```mermaid theme={null}
sequenceDiagram
    participant I as Issuer
    participant W as Holder's wallet
    participant V as Verifier

    I->>W: 1. Offer credential
    W-->>W: 2. Holder accepts, stores credential
    V->>W: 3. Request presentation (shape defined by verifier)
    W-->>W: 4. Holder consents, selects which credential to present
    W->>V: 5. Present (with selective disclosure)
    V-->>V: 6. Verify signature and trust
```

Three things to notice:

* 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                                                     |

The design principle: issuers say what's *possible*, holders decide what's *shared*, verifiers define what's *asked* and what's *accepted*.