Skip to main content

​
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

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.