Skip to main content
The user’s credential lives in a digital wallet. Today that credential is the US mobile driver’s license, presented from Apple Wallet (Safari) or Google Wallet (Chrome). UIP builds the request, the wallet presents the credential, and UIP verifies the signed response. What primitives a given wallet can fulfill is exposed live by the API.

​
Live today

Apple Wallet

US mobile driver’s license (mDL), over the W3C Digital Credentials API in Safari.

Google Wallet

US mobile driver’s license (mDL), over the W3C Digital Credentials API in Chrome.
Both present the same ISO/IEC 18013-5 mobile document, so UIP verifies them identically. Today’s coverage is United States mDL; both wallets support every primitive (identify, age_verify, sign, light_sign).

​
How the wallet flow works

UIP uses the W3C Digital Credentials API (DC_API): the browser, not UIP, talks to the wallet on the device.
1

Request

UIP builds an OpenID4VP request (which fields, a per-request encryption key, a fresh nonce) and the hosted page hands it to navigator.credentials.get().
2

Present

The user approves in their wallet. The wallet returns an encrypted, signed response to the page, which relays it to UIP.
3

Verify

UIP decrypts it server-side and verifies it cryptographically before emitting your webhook.
Because it’s the browser’s native wallet flow, there’s no app to install and the same-device vs cross-device choice is handled for you by the browser’s native flow.

​
The capability matrix

Never hard-code which wallet supports which primitive — read it at runtime. From your backend, call the authenticated GET /v1/catalog, which returns wallet capabilities plus the primitives the platform supports. The hosted page uses the public, no-auth GET /v1/wallets (the user’s browser has no API key). Both derive the per-primitive booleans from the live adapters, so they can’t drift from reality. 
{
  "wallets": [
    {
      "id": "apple-wallet",
      "label": "Apple Wallet",
      "available": true,
      "primitives": { "identify": true, "age_verify": true, "sign": true, "light_sign": true }
    },
    {
      "id": "google-wallet",
      "label": "Google Wallet",
      "available": true,
      "primitives": { "identify": true, "age_verify": true, "sign": true, "light_sign": true }
    }
  ]
}
When you create a session, UIP enforces that the user’s chosen wallet supports the whole chain before any step runs — so a user is never sent into a flow their wallet can’t finish, and you’re never billed for a half-completable chain. A wallet listed but without an active adapter returns a clear “not yet available” rather than a broken flow.