REST API
Get Verification UserInfo
Return user claims and verification provenance for a completed verification.
GET
Returns personal attributes and provenance for the given verification. Use Basic Auth.
Headers
Basic <base64(client_id:client_secret)>.Path Parameters
Verification session id.
Response
Subject identifier. Stable per source identity across all clients.
Numeric assurance level.
Human‑readable assurance label (e.g.,
substantial).Authentication Context Class Reference.
Requested standard claims not provided by the source.
[] for match flows, unless the provider also exposes disclosed claims — then requested-but-unavailable disclosed claims are listed here.Provider identifier that authenticated the subject. Mirrors the single element in
amr.Always present. One of
disclosure (PII under user) or match (comparison envelope under match; user carries the verified subset of the fields you submitted).Personal attributes (present per granted scopes and source availability). When
verification_model is match, contains the verified subset of the fields you submitted via matchData — per-field providers: only fields with matched: true; aggregate providers: every submitted field when the aggregate outcome is true, otherwise empty.Verification context for this event.
Match envelope. Present only when
verification_model is match.Example
Evidence keys are provider-specific. Use
names to determine which fields are present under evidence.token.For match providers,
provenance.presentation.credentials[].claims carries the upstream IDP response verbatim — typically per-field boolean confirmation from the source authority. This is the audit record of what the source agreed with, not a duplicate of match.details. Note the intentional naming asymmetry: matchData, match.submitted_fields, and match.details use OIDC-normalized keys (e.g. name, birthdate), while provenance claims keep the upstream IDP’s native keys (e.g. fullName, dateOfBirth) so the audit trail stays aligned with the source.
