Skip to main content
UIP lets your app ask a user’s government-issued digital credential a precise question and get back a cryptographically verified answer. The credential lives in the user’s own wallet (today: a US mobile driver’s license in Apple Wallet or Google Wallet). UIP builds the request, verifies the wallet’s signed response against the issuing authority’s trust anchors, and delivers the result to you. Three ideas make up the whole model.

​
1. Primitives — the verbs

A primitive is one verified action. You don’t call an “Identity API” or a “Sign API”; you compose primitives.

identify

Disclose specific government-attested fields (“blocks”) — e.g. first_name, dob, country, document_number.

age_verify

Prove the holder meets an age threshold. UIP computes it from the credential’s birth date and returns only the boolean — the date never reaches you.

sign

The holder’s device signs a hash of one or more documents you provide (what-you-see-is-what-you-sign), bound to a verified identity.

light_sign

The same device signature over short inline terms text — no file upload. For consent and acceptance flows.
See Primitives for the full parameter and result shapes.

​
2. Wallets — where the credential lives

Today the credential is a US mobile driver’s license (an ISO/IEC 18013-5 mdoc), presented from Apple Wallet (Safari) or Google Wallet (Chrome) over the W3C Digital Credentials API in the browser. Both wallets return the same mdoc shape, so UIP verifies them identically against the issuing authority’s (AAMVA) trust anchors. Each wallet supports a subset of primitives, exposed live at GET /v1/wallets. See Wallets & coverage for the current map.

​
3. Sessions — one flow for the user

A session bundles the steps you need into a single user experience. You create it server-to-server, then hand the user its hosted URL (as a link or QR). On that page the user’s wallet completes each step on-device; UIP verifies each one and sends you a signed webhook as it happens.
1

Create

POST /v1/sessions with your steps[]. UIP returns a session id and a hosted url.
2

Hand off

Send the user to url — same-device link or cross-device QR. UIP’s page drives the wallet; you host nothing.
3

Verify & deliver

The wallet responds, UIP verifies it cryptographically, and you receive a step.completed webhook with the claims or signature — in order, one per step.
4

Conclude

On the last step (or a gate you set) the session ends with session.completed / session.stopped / session.failed.

​
What UIP is not

UIP never sees a photo of an ID. Claims come from the issuer’s digitally signed credential in the wallet, verified by signature — not by reading a picture. There is no selfie, no liveness check, no document upload to UIP.
UIP discloses only the fields your step requests, only to you, only for that session. age_verify returns a boolean and never reveals the birth date.
There is no UIP “account” the user logs into. The credential stays in their wallet; each session is a fresh, consented disclosure.

Next: Quickstart

Create a session and receive your first verified result.