> ## Documentation Index
> Fetch the complete documentation index at: https://docs.hopae.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Credentials & Providers

> The two layers behind every connection: what a credential proves, what a provider presents, and how the pairing shapes activation, assurance, and claims.

A [connection](/v2/guides/concepts/connections) 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](/v2/guides/verifications/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](/v2/guides/verifications/normalized-user-data).
* **Verification model**: `disclosure` or `match`. See [Verification Model](/v2/guides/concepts/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

| eID type | Example credential | Presented via (provider) |
| :- | :- | :- |
| **Type 1: Centralized IdP** | Smart-ID, MitID, Singpass | the identity service itself |
| **Type 2: Chip-based** | passport, EU ID card | an NFC-scanning app |
| **Type 3: Wallet** | US mDL, EUDI PID | a wallet (Google Wallet, Samsung Wallet, CA DMV Wallet) |

See [Types of eID](/v2/guides/concepts/digital-id-types).

### 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](/v2/guides/verifications/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

| Relationship | Example | What it means for you |
| :- | :- | :- |
| **1 : 1** | `smart-id` ↔ Smart-ID | One connection. Activate it, done. |
| **one provider, many credentials** | Google Wallet → US mDL, passports, Aadhaar | One activation submission can cover several of the provider's connections at once. Each connection is still enabled per workflow. |
| **one credential, many providers** | US mDL ← Google Wallet, Samsung Wallet, CA DMV Wallet | Activate each provider path you want to offer. They can differ in activation type and mode availability. |

<Note>
  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](/v2/guides/concepts/connections/activation).
</Note>

## Related

<CardGroup cols={2}>
  <Card title="Connections" icon="link" href="/v2/guides/concepts/connections">The unit you activate and verify against</Card>
  <Card title="Connection Activation" icon="toggle-on" href="/v2/guides/concepts/connections/activation">Direct, registration, and contract activation</Card>
  <Card title="Level of Assurance" icon="shield-check" href="/v2/guides/verifications/assurance">How assurance is determined per credential</Card>
  <Card title="Normalized User Data" icon="list" href="/v2/guides/verifications/normalized-user-data">The claims a credential returns</Card>
</CardGroup>


This documentation is built and hosted on [Mintlify](https://mintlify.com), a developer documentation platform.