> For the complete documentation index, see [llms.txt](https://docs.openg2p.org/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.openg2p.org/platform/platform-services/vc-issuance/custody-options-and-strategy.md).

# Custody Options & Strategy

How a citizen holds and presents a Verifiable Credential — the three options (paper, hosted wallet, device wallet), who each serves, an honest comparison, and why OpenG2P does paper first and self-own

## The problem isn't issuance — it's custody

Issuing a signed VC is the easy part. The hard part is **how a citizen keeps it and shows it to a verifier**, for an audience that may have **no smartphone, no computer, at most a feature phone, or no device at all**, and limited digital literacy.

Classic Verifiable Credentials are built around a **holder with a device and a wallet** that stores keys and "presents" credentials. That assumption **excludes exactly the population OpenG2P serves**. So a device wallet is the *top* of the pyramid, not the starting point.

## The three options

Ranked by **what the citizen must own** (least → most):

### Option A — Paper credential (lowest common denominator)

* **Citizen owns:** nothing — no device is needed to *hold* the credential.
* **Issuance:** **assisted** — at a kiosk/CSC, an agent (authenticated in the `agent` realm) looks the citizen up by their **national ID**, the citizen **authenticates themselves through eSignet** (biometric at the counter, or OTP to a phone), and only then does Certify issue and sign the credential, which is **printed as a PDF with an offline-verifiable signed QR**.
* **Presentation:** the citizen hands over the paper; a verifier scans the QR with **Inji Verify** (a web portal the verifying organisation hosts, or its embeddable SDK) and checks the COSE signature against a **pre-loaded trust anchor** — the issuer's ES256 key, taken from Certify's JWKS. Claim-169 verification does not resolve DIDs. See [Signatures, Keys and the QR](/platform/platform-services/vc-issuance/signatures-keys-and-the-qr.md).
* **Needs from the citizen:** no device to carry or present it, and no connectivity afterwards — but they **must be able to authenticate once at issuance**. Biometric capture at the counter is what keeps this available to citizens with no phone at all.

### Option B — Hosted wallet (custodial locker)

* **Citizen owns:** a phone (for OTP) **and** access to a real **browser** (own device, kiosk, borrowed, desktop).
* **Mechanism:** credentials stored **server-side** (Mimoto); the citizen **logs in** (phone+OTP) via **Inji Web** to view, re-print, or present online (OpenID4VP). It is the **DigiLocker** model — custodial: the operator holds the keys and credentials.
* **Needs from the citizen:** a browser session + the ability to log in.

### Option C — Device wallet (self-sovereign)

* **Citizen owns:** a **smartphone**.
* **Mechanism:** credentials and keys live **on the device** (Inji Mobile); presentation by QR/BLE offline or **OpenID4VP** online; supports selective disclosure.
* **Needs from the citizen:** a smartphone + the wallet app + some literacy.

## Comparison

| Dimension                          | A — Paper           | B — Hosted                | C — Device                   |
| ---------------------------------- | ------------------- | ------------------------- | ---------------------------- |
| Citizen device required            | **none** to hold¹   | browser access            | smartphone                   |
| Works fully offline (citizen side) | ✅                   | ❌ (needs login)           | ✅                            |
| In-person verification             | ✅ scan QR           | ✅                         | ✅                            |
| Remote / online presentation       | ❌                   | ✅                         | ✅                            |
| Holder-bound (anti-copy)           | ❌ bearer (copyable) | ✅ bound to login          | ✅ bound to device key        |
| Selective disclosure / privacy     | ❌ all-or-nothing    | partial (server sees all) | ✅ best                       |
| Live revocation at presentation    | ❌ offline           | ✅                         | ✅                            |
| Recovery if lost                   | re-issue at kiosk   | ✅ re-login                | ❌ unless backup              |
| Keys held by                       | n/a                 | **operator (custodial)**  | **citizen (self-sovereign)** |

¹ Holding and presenting paper needs no device. **Issuance** does require the citizen to authenticate once via eSignet — biometric at the counter needs nothing of them; OTP needs a phone.

## Who each option actually serves

* **Device-less citizen → A (paper).** The only option that needs nothing from them.
* **Feature-phone citizen → still A.** A feature phone only *receives an OTP*; it can't run a wallet app **or** the hosted-wallet browser UI. So the OTP alone unlocks nothing — they're served by paper (or an assisted/borrowed browser, which is really B-with-help).
* **"Browser-but-no-smartphone" citizen → B.** A genuine but **narrow and shrinking** slice: has a phone + occasional browser access (kiosk/borrowed/desktop) but no smartphone, and needs *online* presentation. Squeezed from below by paper (in-person) and above by smartphones.
* **Smartphone owner → C.** The device wallet is **strictly more capable** than the hosted wallet for them (on-device keys, offline, privacy, control). A hosted wallet adds them almost nothing.

### What the hosted wallet uniquely enables — and its limits

The only things paper fundamentally cannot do, that a wallet can: **remote/online presentation (OpenID4VP)** and **holder-bound (non-copyable) presentation**. But:

* these matter only when **online relying parties** accept VCs and/or **fraud/privacy** pressure is real — for purely **in-person** interactions, paper already suffices;
* the hosted wallet's convenience benefits (durability, re-access, freshness) are largely matched in Phase 1 by **re-issue-on-demand** at a kiosk (the data lives in the registry; Certify is stateless);
* and for a smartphone owner, the **device wallet** delivers those same capabilities, better.

## The deeper point: B vs C is a *policy* choice, not just a tier

Hosted vs device is **custodial vs self-sovereign**:

* **Hosted (B) = custodial locker.** The operator holds the citizen's keys/credentials; centrally **recoverable, assist-able, works without owning a device**. Some governments *prefer* this (DigiLocker-style) as the primary digital channel.
* **Device (C) = self-sovereign.** The citizen holds keys; maximal privacy/control; but must own and manage a device, and losing it (without backup) loses the credentials.

So "skip B, go A → C?" is really: *does the program want a government-run custodial locker as a first-class channel, or self-sovereign wallets?* OpenG2P's direction is **self-sovereign**, so B is not a default tier.

## The strategy

| Phase       | Option                             | Audience                               | Why                                                                                          |
| ----------- | ---------------------------------- | -------------------------------------- | -------------------------------------------------------------------------------------------- |
| **1 (now)** | **A — Paper**                      | device-less majority (+ feature-phone) | Lowest common denominator; needs nothing from the citizen; removes all wallet/IdP complexity |
| **2**       | **C — Device wallet** (self-owned) | smartphone owners (growing)            | Self-sovereign; full offline + online presentation                                           |
| —           | **B — Hosted wallet**              | "browser-no-smartphone" minority       | **Considered, not chosen** — adopt only as a deliberate custodial-locker policy              |
| separate    | Consent-based data sharing         | dept ↔ dept / third parties            | Registry partner APIs + consent — not a wallet feature                                       |

**Consequence:** Phase 1 needs an **Agent Portal API** (reads the Registry, pushes claims) + **eSignet** (authenticates the beneficiary) + **Certify (issue + sign)** + a **signed QR/PDF** + **Inji Verify**. No Mimoto, no hosted-wallet login, no OpenID4VCI device flow, and no citizen wallet — i.e. none of the integration complexity those paths require. eSignet authenticates the beneficiary at the counter; the citizen never logs in to anything afterwards. See [Phase 1 — Paper Credential](/platform/platform-services/vc-issuance/phase-1-paper-credential.md).


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.openg2p.org/platform/platform-services/vc-issuance/custody-options-and-strategy.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.