Aadhaar serves as a proof of identity and address, anywhere in India. Aadhaar letter received via India Post and e-Aadhaar downloaded from UIDAI website are equally valid.

Key Actors in Aadhaar Authentication

Unique Identification Authority of India (UIDAI): UIDAI is the overall regulator and overseer of the Aadhaar authentication system. It owns and manages the Central Identities Data Repository (CIDR) that contains the personal identity data (PID) of all Aadhaar-holders.

Authentication Service Agency (ASA): ASAs are entities that have secure leased line connectivity with the CIDR. ASAs transmit authentication requests to CIDR on behalf of one or more AUAs. An ASA enters into a formal contract with UIDAI.

Authentication User Agency (AUA):An AUA is any entity that uses Aadhaar authentication to enable its services and connects to the CIDR through an ASA. An AUA enters into a formal contract with UIDAI.

Sub AUA:An entity desiring to use Aadhaar authentication to enable its services through an existing AUA. Examples: (i) IT Department of a State/UT could become an AUA and other departments could become its Sub AUAs to access Aadhaar authentication services. (ii) A Hoteliers Association becomes an AUA and several hotels could access Aadhaar authentication as its Sub AUAs. UIDAI has no direct contractual relationship with Sub AUAs.

Authentication Devices: These are the devices that collect PID (Personal Identity Data) from Aadhaar holders, transmit the authentication packets and receive the authentication results. Examples include PCs, kiosks, handheld devices etc. They are deployed, operated and managed by the AUA/Sub AUA.

Aadhaar holders: These are holders of valid Aadhaar numbers who seek to authenticate their identity towards gaining access to the services offered by the AUA.

The key actors could engage with each other in multiple ways. For example, an AUA could choose to become its own ASA, an AUA could access Aadhaar authentication services through multiple ASAs for reasons such as business continuity planning, an AUA transmits authentication requests for its own service delivery needs as well as on behalf of multiple Sub AUAs.

Similarly, it may also be possible to use a single authentication device for servicing multiple AUAs. For example, the authentication device at a fair price shop may also be used for carrying out financial transactions for banks.

authentication process
Federated Model

UIDAI offers Aadhaar authentication that can be used alone or in conjunction with AUAs domain/application specific authentication scheme (called "federated authentication"). For example, in federated authentication, a Bank could choose to use an ATM card and fingerprint for authentication of which the ATM card is authenticated within Bank's application whereas the fingerprint is authenticated against data in the CIDR using Aadhaar authentication.

Most current authentication systems can be described as "local" (i.e., pertaining to and/or valid for a few services, situations or entities) and "revocable" (wherein an existing identity factor could be revoked and reissued as a result of expiry, compromise or other valid reasons). Aadhaar authentication system, on the other hand, could be described as "global" (because of its applicability across AUAs and services) and "non-revocable" (because Aadhaar identity factors such as fingerprints and iris scans cannot usually be revoked/replaced).

In the federated authentication model, the global-irrevocable Aadhaar authentication co-exists with and strengthens the local-revocable authentication of AUAs. Such a federated approach would result in authentication systems that are stronger and more reliable than those that are based either only on global-irrevocable model or only on local-revocable model.

While the federated model does not mandate the existence or use of an AUA’s own authentication (if an AUA/ Sub-AUA so wishes, they could use only Aadhaar authentication by itself), AUAs/ Sub-AUA are encouraged to use Aadhaar authentication in conjunction with their existing authentication to render the overall authentication system stronger and more reliable.

Handling Network Exceptions

Online authentication essentially requires network connectivity. For cases where connectivity is intermittent or connectivity is a little distance away, UIDAI proposes a solution called "buffered" authentication wherein authentication request may be "buffered" (or queued) on the device until a pre-specified period of time, which is currently 24 hours, and then sent to CIDR for authentication when connectivity is restored / available.

Even though the authentication device may transmit multiple authentication requests at the same time in case multiple buffered requests are sent simultaneously, each authentication request will be treated as a separate transaction in the Aadhaar authentication system. In addition, UIDAI expects that buffering would only be done at the device level and not at AUA / ASA server end.

Handling Biometric Exceptions

As in any other technology, biometric technology too has its own limitations. There would be a very small fraction of the population with all biometrics (both fingerprint and iris) missing who may not be able to avail any biometric authentication. Further, there would be a set of people who may not be able to avail fingerprint-based authentication such as people with missing fingers, people having very poor quality fingerprints. In addition, there could be a set of people with temporary problems in biometric authentication such as cut/burnt fingers, extreme environmental conditions etc.

UIDAI recommends that AUAs opting for biometric authentication should have alternate mechanisms to service genuine residents who are not able to use biometric authentication. Some solutions could be using alternate biometric modalities, allowing multiple attempts, operator authentication, using demographic / OTP based authentication etc. Adopting federated model is also expected to aid handling of biometric exceptions.