OIDC
UserInfo
Returns user claims based on granted scopes. Requires a valid Bearer access token.
GET
Fetch verified user claims using the access token from
/token.
The ID Token contains no PII. All personal attributes are returned only by
/userinfo.
Unsupported (requested) standard claims are listed in missing_claims.
Verification context is provided in provenance. Evidence is included when the credential source returns it; the object contains a token payload and a semicolon‑delimited names list describing the keys. Keys vary by provider, so always read them from names. Content is relayed from the credential source.Headers
Bearer access token issued by
/token.Responses
Subject identifier. Stable per source identity across all clients.
Authentication Context Class Reference.
Numeric assurance level.
Human‑readable assurance label (e.g.,
substantial).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. Inspect
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.
