Skip to main content
A successful verification returns a presentation. It has three parts, joined together in one token: The token is wrapped in a standard W3C Verifiable Presentation. The wrapper and the result status around it are not signed; only the token inside is.

​
Choosing which claims are shared

Three settings decide which claims appear:
  1. The issuer marks claims as shareable and turns on Allow data disclosure for its issuance program. Without that, no claims are shared, although the credential can still be verified.
  2. The verifier lists the claims it wants (fieldsToDisclose), or * for every shareable claim. This is required for SD-JWT programs.
  3. The user approves the request.
Requesting a claim the issuer did not make shareable is not an error; that claim is simply absent.

​
The holder signature

The holder signature proves that the person presenting the credential is the person it was issued to, right now, for you. AIR Kit adds it when both are true:
  • your app passed a one-time challenge, and
  • the credential contains a holder key, which every AIR-issued credential does.
It covers your challenge (so it cannot be replayed), your program ID (so it cannot be reused for another program), the time, and the exact set of shared claims (so none can be added or removed later). Without a challenge, the presentation is a bearer token: anyone who obtains a copy can present it.
The Web SDK accepts a challenge. The Flutter SDK’s verifyCredential does not take one, so its presentations are bearer tokens.

​
What each part proves

To know the credential has not been revoked, check the issuer’s revocation status. See Checking a presentation. For how the token is built, see How SD-JWT credentials work. For the exact format, see Verify with SD-JWT.