Aadhaar Verifiable Credentials: A Developer Guide
Learn how Aadhaar Verifiable Credentials work in the Aadhaar App, what OVSEs must verify, and how selective sharing changes identity checks.
The Aadhaar App can now share a digitally verifiable identity credential without transferring the holder’s 12-digit Aadhaar number to the verifier. UIDAI’s April 2026 circular confirms that Aadhaar Verifiable Credentials shown, shared, or verified through the app are a legally valid way to establish identity alongside Aadhaar letters, e-Aadhaar, masked Aadhaar, Aadhaar cards, and mAadhaar.
That changes the integration question. You no longer need to ask only, “Did the user upload an Aadhaar image?” You need to ask what was shared, who issued it, whether it is authentic and current, and what evidence your application is allowed to retain.
What is an Aadhaar Verifiable Credential?
An Aadhaar Verifiable Credential is a digital identity artifact the Aadhaar holder can show or selectively share through the Aadhaar App. UIDAI says the app can share complete or partial identity details with an Offline Verification Seeking Entity (OVSE), while the 12-digit Aadhaar number is not transferred.
This is different from taking a screenshot of an Aadhaar card. A screenshot gives you pixels. A verifiable credential gives a verifier structured claims plus cryptographic evidence that should be checked using the applicable UIDAI specification and trust material.
It is also different from online Aadhaar authentication. Online authentication is performed through the regulated AUA/KUA ecosystem. Offline verification is resident-initiated and follows the OVSE requirements. Do not describe your company as an AUA, KUA, Sub-AUA, or Sub-KUA unless it actually holds that role.
Selective sharing reduces unnecessary data collection
The Aadhaar App lets a holder share selected identity details rather than always exposing every available field. That supports a useful privacy rule: collect the minimum data needed for the stated purpose.
If a service needs to establish age eligibility, it may not need a complete address. If it needs a name match, it may not need to retain a portrait after verification. Your product should define required claims by use case instead of accepting every field and deciding later.
Create a claim matrix before integration:
| Business purpose | Required claim | Retain after verification? | Retention reason |
|---|---|---|---|
| Age eligibility | Age or date-of-birth result | Prefer derived result | Eligibility evidence |
| Name matching | Name | Only if the workflow requires it | Account or contract record |
| Address proof | Address | According to the documented purpose | Delivery or regulated process |
| Duplicate prevention | Approved derived identifier | Avoid raw credential reuse | Fraud control |
The exact fields and retention policy depend on your lawful purpose, contract, and applicable rules. “The credential contained it” is not a retention justification.
Verification needs five separate checks
A production verifier should treat these as separate decisions:
- Format: the credential parses according to the supported specification and version.
- Issuer trust: the issuer and signing material chain to the trust source required by UIDAI.
- Cryptographic integrity: the signature covers the expected bytes and validates with an allowed algorithm.
- Status and freshness: the credential is within its validity rules and any required status check succeeds.
- Business policy: the claims satisfy your use case without requesting or retaining extra data.
Do not collapse those checks into a single verified: true flag. Store reason codes such as signature_invalid, credential_expired, or required_claim_missing. They help support teams diagnose failures without logging the entire credential.
Store evidence, not a copy of everything
The safest record is often a verification receipt rather than the raw credential. A receipt can contain the credential type and version, verification time, issuer identifier, policy version, result, selected non-sensitive claim outcomes, and a privacy-safe correlation ID.
Avoid logging the complete credential, QR payload, Aadhaar number, face image, or device data. Protect any retained identity attributes with strict access controls and a deletion schedule. Our authentication data-retention guide explains how to separate security evidence from indefinite personal-data storage.
Design failure and support paths before launch
A valid holder may be unable to share a credential because the device is offline, the app is outdated, the requested attribute is unavailable, or the verifier does not support the credential version. Give the user a clear fallback that is approved for the same purpose.
Do not turn a parsing error into “identity fraud.” Distinguish technical failure, policy mismatch, and suspected tampering. Rate-limit repeated submissions, but keep an accessible manual-review route for legitimate users.
Aadhaar credentials do not replace application login
Identity verification answers a point-in-time question about presented evidence. Authentication answers whether the current person controls an application account. Authorization answers what that account may do. Keep those layers separate.
After verification, bind the result to the correct authenticated account, record the purpose, and prevent the verification response from becoming a reusable bearer credential. For the wider choice among rails, read Aadhaar vs DigiLocker vs offline KYC.
Contact the NamoID team
NamoID can help your team design the login, authorization, consent-evidence, and audit boundary around an Aadhaar verification workflow. NamoID does not grant Aadhaar ecosystem eligibility or replace UIDAI guidance, but the team can review how verification results enter your application without becoming an unsafe identity shortcut.
Message the NamoID team in Slack with your use case, required claims, and retention constraints. We can help you map the integration and respond early.