Skip to main content
A connection pairs a credential with a provider. Keeping them separate is what lets the same identity be presented from more than one place, and what lets you reason about assurance and claims independently of the channel.

Credentials

A credential is the verifiable identity artifact, the thing that actually proves who the user is. It determines what is proven:
  • Issuer: the authority behind the identity (a government, a bank, an identity scheme).
  • Assurance: the strength of the verification, surfaced as a Level of Assurance. A credential advertises the levels it can reach. The achieved level is reported per verification.
  • Claims: the normalized attributes it can return (name, birthdate, nationality, …). See Normalized User Data.
  • Verification model: disclosure or match. See Verification Model.
  • Countries and the display name end users see.
Credential ids are scoped and descriptive: us-mdl (US mobile driver’s license), cz-bankid-identify (a BankiD CZ product tier), id-nik-bio-match (Indonesian NIK with biometric match).

Credentials across eID types

See Types of eID.

Product variants

Some credentials come in variants that differ in assurance or claims, such as BankiD CZ Connect / Identify / Identify Plus, Indonesia NIK basic / biometric. Each variant is its own credential, and therefore its own connection. Variants the end user cannot tell apart share one row in the hosted selection UI. Your workflow decides which variant runs. See Workflows.

Providers

A provider is the holder or channel that presents a credential. It determines where the identity lives and how it is presented, and it owns the activation procedure, because it is the provider, not the document, that needs to know who is relying on it.
  • Direct providers (most national-ID lookups, wallets like CA DMV Wallet or Samsung Wallet) activate instantly.
  • Registration providers (Smart-ID, MitID, BankID Sweden, Google Wallet) collect a few company details and review them.
  • Contract providers (Singpass, BankID Norway, eParaksts) need an agreement arranged with Hopae.
Provider ids are short slugs: google-wallet, smart-id, cz-bankid, freja.

How the pairing plays out

Activation happens per connection (grouped by provider when you submit), never for a whole provider. Activating Google Wallet for the US mDL does not make Google Wallet’s passport connections available. See Connection Activation.

Connections

The unit you activate and verify against

Connection Activation

Direct, registration, and contract activation

Level of Assurance

How assurance is determined per credential

Normalized User Data

The claims a credential returns