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. 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 returns it as credential.verificationModel for every connection activated for your app, and 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.

​
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. 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 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".
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.

​
Comparison

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.