Skip to main content
Verification lets an app check a fact about a user, such as “holds a Gold membership”, without seeing anything else. The user’s device finds the matching credential, the user approves what is shared, and the app receives a presentation: the approved claims, still carrying the issuer’s signature. The app’s backend checks that signature before acting on it.

​
The verification program decides what to check

Apps do not describe the check in code. They pass a program ID, and the verification program configured in the Developer Dashboard defines: Changing what you require is a Dashboard change, not a code deploy.

​
The flow

  1. Challenge. Your backend creates a one-time random challenge (a nonce) for this attempt.
  2. Find and decrypt. AIR Kit finds the user’s matching credential in encrypted storage and decrypts it on the user’s device. AIR only handles ciphertext.
  3. Consent. The user sees exactly which claims will be shared. If they decline, nothing is shared.
  4. Present. AIR Kit builds the presentation: the issuer-signed credential with only the approved claims, plus the user’s signature over your challenge.
  5. Check. AIR Kit checks the presentation in the browser for a quick answer. Your backend then checks it properly before granting anything.
The browser’s Compliant result is not proof to your backend; it is not signed. Only the presentation is. See Checking a presentation.

​
Ways to verify

​
In this section

What the verifier receives

The parts of a presentation and what each one proves.

Checking a presentation

What your backend checks, and why.

Results and errors

Every outcome and how to handle it.

Zero-knowledge verification

Proving conditions with Iden3 credentials.
To build a verifier, follow the developer guide: Verifying credentials.