Aadhaar Offline e-KYC XML: How to Verify It

Verify an Aadhaar offline XML signature before using its fields for an identity decision. Use an independently trusted UIDAI certificate. Then apply your purpose, freshness and retention rules to the verified content.

An offline check avoids a live authentication request to UIDAI's central database. It still needs an appropriate legal and operational basis. The permitted mode and the organisation's role determine the applicable requirements.

Check the current offline verification route

The Aadhaar framework distinguishes online authentication from offline verification. Regulation 13A addresses registration for specified offline verification modes. UIDAI also publishes an Offline Verification Seeking Entity, or OVSE, registration route. Confirm how these rules apply to your exact workflow. UIDAI regulations, OVSE guidance.

Avoid a blanket “no licence needed” claim. A locally verified signature does not establish your organisation's eligibility, permission to collect fields, or authority to act for another organisation.

For other document routes, use the Aadhaar and DigiLocker comparison.

Separate the ZIP password from identity verification

In the file-sharing flow, the holder obtains a protected ZIP and supplies its share code. The code unlocks the archive. A successful unzip does not prove that UIDAI issued the XML or that its contents remain intact.

Keep the archive, share code and extracted XML out of logs. Bound the compressed and expanded sizes. Reject unexpected archive entries and XML structures. Use a maintained XML-signature library with secure parsing.

Our verification example demonstrates the signed-content boundary with synthetic fixtures. It does not contact UIDAI or establish an approved production integration.

Read the content that passed signature verification

The important boundary is the object returned by signature verification. Read the identity fields from that verified object. Reading a different XML node can undermine an otherwise successful cryptographic check. SignXML documents this signed-content discipline. SignXML verification guidance.

from lxml import etree
from signxml import XMLVerifier
 
def verified_identity(xml_bytes: bytes, trusted_certificate: bytes) -> str:
    if len(xml_bytes) > 1_048_576:
        raise ValueError("XML exceeds the example limit")
    parser = etree.XMLParser(resolve_entities=False, no_network=True)
    document = etree.fromstring(xml_bytes, parser=parser)
    result = XMLVerifier().verify(document, x509_cert=trusted_certificate)
    signed = result.signed_xml
    if signed.tag != "OfflinePaperlessKyc":
        raise ValueError("Unexpected signed document")
    identity = signed.find("UidData/Poi")
    if identity is None or not identity.get("name"):
        raise ValueError("Verified identity is incomplete")
    return identity.get("name")

This example expects the illustrated unnamespaced document shape. Match the accepted structure and signature profile to your approved source. Obtain signing certificates through a trusted channel. Plan certificate rollover and any required validity or status checks separately.

The example's size bound is an application limit. It is not a UIDAI requirement. The complete downloadable example rejects document type declarations and includes tamper and wrong-certificate tests.

Apply freshness and account-binding checks

A valid signature establishes the integrity of the signed material under the trusted key. It does not establish current address, current account control or the present user's authority to use a record.

1. Bind the upload to a signed-in application account.
2. Verify the signature before making an identity decision.
3. Check the document's relevant time fields.
4. Apply your documented freshness rule.
5. Compare only the fields required for the task.
6. Record the bounded outcome and applicable policy version.

Treat missing or ambiguous evidence as a review outcome. Do not silently change a failed signature result into a successful check.

Distinguish returned data from stored data

NamoID's current Aadhaar endpoint parses an uploaded XML or ZIP and returns fields with verification flags. The endpoint does not write a verification record. Its response is broader than a last-four identifier and a name hash.

If no certificate is configured, a returned payload is not a successful signature verification. Consumers must inspect both flags before using the fields as verified evidence.

The response itself contains personal data. A downstream database, exception logger, browser trace or support system can retain it independently. A derived hash can also remain linkable. Review each boundary rather than describing the entire flow as “nothing stored.”

Define retention for the actual purpose

Record which result fields the application needs and who can access them. Set deletion and evidence requirements for each recipient. Keep a short verification outcome where sufficient. Do not turn a reduced storage example into a universal permission to retain Aadhaar-derived data.

Use the authentication retention guide to map databases, queues, logs and backups. For account recovery, keep document evidence separate from the recovery authorization decision.

Review your verification boundary with NamoID

NamoID engineers can help review the current adapter, response handling and account binding. Bring your stack, intended purpose and a synthetic example. Message the team in Slack for an early response. Contact NamoID in Slack