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

# Verification Model

> How the disclosure and match verification models shape the response you read

## Overview

Every verification result carries a top-level `verification_model` field that tells you **which question the provider answered** — and therefore which part of the response to read. It is always present; sessions created before the field existed default to `"disclosure"`.

There are two models:

* **`disclosure`** — the provider *discloses* user attributes from an authoritative source. You read who the user is.
* **`match`** — the provider *matches* values you submitted against the authoritative source and returns a pass/fail outcome. You read whether your values were confirmed.

## `disclosure` model

The default for classic eID providers. The provider returns verified personal attributes.

* Read identity attributes from `user.*` (for example, `user.name`, `user.birthdate`).
* `provenance` describes how the identity was verified.
* Claims you requested but the provider could not supply appear in `missing_claims`.

This is the model used by the standard QR / redirect / push flows and by Digital Credentials wallet providers.

## `match` model

Used by match-capable providers. Instead of disclosing attributes, the provider compares values **you** submit (the `matchData` supplied at session creation) against the source of truth.

* Read the outcome from `match.*` — `match.matched` (aggregate result), `match.granularity` (`per_field` or `aggregate`), `match.submitted_fields`, and `match.details`.
* For match flows, `user` echoes back only the **verified subset** of the fields you submitted: per-field providers include fields with `matched: true`; aggregate providers include every submitted field when the aggregate outcome is `true`, otherwise none.
* A match provider may additionally disclose IDP-asserted claims under `user`, but only when you request them via `requestedAttributes`.

## Comparison

| | `disclosure` | `match` |
| - | - | - |
| **Question answered** | "Who is this user?" | "Do these values match the source?" |
| **Read result from** | `user.*` and `provenance` | `match.*` and `provenance` |
| **`user` contains** | Disclosed PII | Verified subset of your submitted fields |
| **RP input required** | Requested claims | `matchData` at session creation |
| **Typical providers** | Classic eIDs, DC wallets | Match-capable providers |

<Note>
  Both models return the full `provenance` block, so you always have the verification audit trail. For the complete payload schema and the field-by-field `match` reference, see [Return Data](/guides/verifications/return-data-model).
</Note>

## Related

* [Return Data](/guides/verifications/return-data-model) — the full UserInfo payload and `match` schema
* [Create Verification](/api-reference/verifications/create-verification) — supply `matchData` for match flows
* [Normalized User Data](/guides/verifications/normalized-user-data) — the OIDC-normalized keys used in `matchData`


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.