Skip to main content
Return Data

​
Overview

  • Who is the user? → returned under user.
  • How was this identity verified? → described by provenance.

​
What “Provenance” Means

Provenance explains the verification story — who vouched for the identity, how it was presented, and when it happened.
  • Presentation
    • Channel: the route and transport (for example, centralized_idp over internet, chip_based via nfc, wallet over internet).
    • Credentials[]: the documents or assertions that were presented (type is the provider identifier, alongside issuer details and raw upstream claims).
    • Evidence (when provided)
      • Evidence is included when the credential provides it; the object relays the upstream token payload and a semicolon-delimited names list describing the keys. Key names are provider-specific—always read them from names. Content is relayed from the credential source.
  • Metadata
    • Verification identifiers and timestamps for audit and support (verification_id, verified_at).

​
UserInfo Payload Structure

Here is a conceptual map of the UserInfo payload. This tree view shows how the data is organized, with a brief explanation for each major component. For detailed field specifications, refer to the Schema Tables that follow this section. 
{
  // --- Identity ---
  "sub": "...",                // Unique subject identifier
  "user": {                     // Personal attributes (from /userinfo)
    "name": "...",
    "birthdate": "..."
  },

  // --- Assurance ---
  "acr": "...",
  "hopae_loa": 3,
  "hopae_loa_label": "substantial",
  "missing_claims": ["email", "address"],

  // --- Verification Story ---
  "provenance": {
    "presentation": {
      "channel": { "type": "...", "transport": "..." },
      "credentials": [
        {
          "type": "smartid",
          "issuer": { "id": "...", "authority_name": "...", "is_government": false },
          // `type` matches the providerId you supplied when creating the session; evidence keys vary per provider
          "evidence": {
            "token": {
              "<token_key>": "...",
              "<another_key>": "...",
              "...": "..."
            },
            "names": "<token_key>;<another_key>;..."
          }, // optional, may be absent
          "claims": { ... }
        }
      ]
    },
    "_metadata": { "verification_id": "...", "verified_at": "..." }
  }
}

​
Next Steps

OIDC Provider

How OIDC fits into User Verification

Verification Flow

Understand the end-to-end lifecycle