The flow
Step by step
1
The app starts issuance
Your app calls AIR Kit with a Partner JWT and the issuance program. If the user is not signed in to AIR, AIR Kit signs them in first. AIR then knows who the user is and which keys belong to them.
2
The issuer prepares a preview
AIR asks the issuer which credentials this user can claim. The issuer looks the user up by the partner user ID that AIR resolves from the signed-in session, loads the claims, and returns a preview encrypted to the user.A preview is not a credential: it is unsigned and stored nowhere. AIR passes it along without being able to read it.
3
The user reviews and confirms
AIR Kit decrypts the preview on the user’s device and shows it. Nothing is issued unless the user confirms.
4
The issuer issues
AIR asks the issuer to issue, passing the user’s public signing and encryption keys. The issuer loads the claims again from its own systems rather than trusting the preview, then builds the credential, binds it to the user’s key, signs it, encrypts it, and stores it in DStorage.
5
The app gets the result
AIR Kit resolves once the credential is stored. A record of its hashes and status is also written to Moca Chain. If your next step is verifying the credential straight away, ask AIR Kit to wait for that record (
waitForOnchainCompletion), because an immediate verification can fail while it is pending.What each party sees
Things to know
- AIR calls the issuer’s endpoints server to server with the issuer’s API key. The browser never sees that key, and claims reach it only encrypted, to be decrypted on the user’s device.
- The issuer authorizes each request with the partner user ID AIR resolved, not with the holder DID alone.
- A typical issuance completes in about 1 to 4 seconds.