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

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.

The model is a property of the **connection**. [Get Connections](/v2/api-reference/verifications/get-connections) returns it as `credential.verificationModel` for every connection activated for your app, and [Create Verification](/v2/api-reference/verifications/create-verification) echoes it so you know which shape to expect before the user has done anything.

## `disclosure` model

The default for classic eID providers and digital wallets. 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 the workflow requested but the provider could not supply appear in `missing_claims`.

Some disclosure connections need a lookup key before they can start (a registration id, a phone number). Send it in `userInput`. The connection's `userInputSchema` lists the fields. See [User Input](/v2/api-reference/verifications/user-input).

## `match` model

Rather than disclosing attributes, the provider compares values **you** submit against the source of truth and returns a pass/fail outcome.

* **Input: `userInput`.** Supply the values to check when you create the verification, keyed by [OIDC-normalized names](/v2/guides/verifications/normalized-user-data). The same single map carries any lookup key the provider needs. Hopae decides which values are compared and which select the record. The connection's `userInputSchema` tells you which fields are required.
* **Outcome: `match.*`.**
  * `match.matched`: the overall result, `true` only when **all** submitted fields matched.
  * `match.granularity`: `per_field` or `aggregate` (also advertised as `credential.matchGranularity` on the connection).
  * `match.submitted_fields`: the fields you submitted.
  * `match.details`: per-field results (`matched`, `submitted_value`, optionally `similarity` 0 to 100). Populated for `per_field`. For `aggregate` the per-field flags are omitted. See [Return Data](/v2/guides/verifications/return-data-model) for the schema.
* **Echoed `user`.** `user` carries only the **verified subset** of your submitted fields, restricted to the connection's recognized match fields, primitive values only:
  * `per_field` → fields whose `matched` is `true`.
  * `aggregate` → every submitted field when `match.matched` is `true`. Otherwise none.
* **Partial or failed matches.** A field the provider does not confirm counts as not matched. If the match cannot be computed at all, the verification **fails** instead of returning a result.
* **Dual providers.** Some match connections can *also* disclose provider-asserted claims under `user` when the workflow requests them. On a key collision the disclosed value wins, and the result still reports `verification_model: "match"`.

<Note>
  Every match connection in the catalog today uses `per_field` granularity. `aggregate` is the all-or-nothing fallback used when a provider reports only an overall result.
</Note>

## 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 |
| **Your input** | Claims chosen in the workflow (plus a lookup key in `userInput` when the connection needs one) | The values to compare, in `userInput` |
| **Typical connections** | Classic eIDs, digital wallets | National registry lookups such as `br-cpf-cnh-match`, `id-nik-match` |

<Note>
  Both models return the full `provenance` block, so you always have the verification audit trail. For match flows, the per-credential `provenance` entries carry the source's own confirmation response (for example per-field booleans) rather than the attribute values. For the complete payload schema and the field-by-field `match` reference, see [Return Data](/v2/guides/verifications/return-data-model).
</Note>

## Related

* [Connections](/v2/guides/concepts/connections): where the verification model is defined
* [Workflows](/v2/guides/verifications/workflows): configure claims, connections, and branding for a verification
* [Return Data](/v2/guides/verifications/return-data-model): the full UserInfo payload and `match` schema
* [Create Verification](/v2/api-reference/verifications/create-verification): supply `userInput` for match flows
* [Normalized User Data](/v2/guides/verifications/normalized-user-data): the OIDC-normalized keys used in `userInput`


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