Authentication User Agencies

Authentication User Agencies

To be added

Introduction

AUA is any government / public / private legal agency registered in India that seeks to use Aadhaar authentication for its services. An AUA is the principal agency that sends authentication requests to enable its services / business functions.

An AUA connects to the CIDR through an ASA (either by becoming ASA on its own or contracting services of an existing ASA).

Examples of AUAs:

Department of Civil Supplies, which seeks to verify the identity of a target resident before issuing them their monthly ration of rice, kerosene, etc.

Any bank / financial institution that seeks to verify the identity of its customer before letting them complete a financial transaction such as withdrawal or transfer of funds.

The administration/security department of a high-security building/zone that seeks to verify the identity of any individual seeking entry into the building/zone.

AUA Readiness Stages

  • Identify business / service delivery needs-The agency needs to identify service delivery areas where Aadhaar authentication may be used. The agency also needs to decide what authentication types they would be using for Aadhaar enabling different service delivery needs.
  • Fill online application form-Any agency interested in becoming an AUA needs to apply online. UIDAI has an online workflow based application form for engaging with AUAs.
  • Engage with ASA(s):One of the initial stages for becoming a requesting entity is the need to engage with an existing ASA. The list of approved ASAs would be available online and an interested requesting entity can engage accordingly. In case a requesting entity wants to become both ASA and requesting entity, it would first need to get approved as an ASA and then apply for becoming a requesting entity.
  • Send signed contract and supporting documents to UIDAI: The requesting entity should send hardcopy of the signed contract along with required supporting documents to UIDAI. The online application would be approved by UIDAI upon receipt of the required documents.
  • Ensure process and technology compliance:The requesting entity needs to setup necessary systems, processes, infrastructure etc. in compliance with UIDAI standards and specifications, as specified in the AUA Handbook . Some such requirements include defining exception handling mechanism, developing application using Aadhaar authentication APIs, ensuring connectivity from authentication devices to the requesting entity server etc. Compliance to various requirements needs to be confirmed to UIDAI through the online application process.
  • Plan device deployment: The requesting entity needs to decide upon the authentication device specifications based on its business requirements and ensure deployment of same. If a requesting entity opts for biometric authentication, the sensor/extractor of the biometric devices needs to be certified by a certifying body such as STQC that has been authorized by UIDAI. If a requesting entity opts for operator-assisted devices, the AUA would also need to ensure training and readiness of operators.
  • Obtain approvals from UIDAI:UIDAI would approve an application form from a requesting entity when various compliance requirements are met. A requesting entity should engage with UIDAI during the process and provide required clarifications.
  • Carry out end-to-end testing: Approval from UIDAI allows a requesting entity to carry out end-to-end testing of their application with the CIDR. Before going live with actual resident authentication, it is highly recommended that the requesting entity carries out thorough end-to-end testing of their application with the selected ASA and with CIDR. The requesting entity should get the systems related to Aadhaar authentication audited by information systems auditors certified by a recognized body before going live.
  • Go-live: A requesting entity can go-live after confirmation of adherence to all UIDAI’s standards and specifications. UIDAI plans to manage the same through online workflow based application.

Key AUA Responsibilities

  • Choose an appropriate authentication type based on business and deployment risk assessment; inform UIDAI regarding the same.
  • Ensure compliance of authentication related operations (processes, technology, security, etc.) to UIDAI’s standards and specifications as specified in the AUA Handbook
  • Deploy fraud monitoring mechanism, as per AUA’s business needs, to prevent misuse of exception handling mechanism by operators and any other ecosystem members, as mandated through Chapter VI of Aadhaar Act 2016 .
  • Get its operations and systems related to Aadhaar Authentication audited as per UIDAI’s specifications specified in the AUA Handbook and in accordance with the provisions of the Aadhaar Act 2016.
  • Ensure connectivity from authentication devices to the AUA server and between the AUA server and the ASA server.
  • Procure, deploy and manage certified biometric devices in compliance with UIDAI’s latest biometric device specifications.
  • Ensure adequate training for the personnel managing authentication devices and bring an awareness for compliance aspects relating to Protection of Aadhaar number holder information, penalties associated with unauthorized usage, misuse of data etc, as specified in Chapter VI and Chapter VII of the Aadhaar Act 2016 and Aadhaar Authentication Regulations 2016.
  • Inform UIDAI of the engagement/ disengagement of Sub AUAs.
  • Ensure supported Sub AUAs comply with UIDAI’s standards and specifications.
  • Inform UIDAI of any misuse of Aadhaar data, authentication services, or any compromise of Aadhaar related data or systems and ensure compliance to Aadhaar Act 2016.

Mandatory Security Requirements

  • Aadhaar number should be never used as a domain specific identifier.
  • In the case of operator assisted devices, operators should be authenticated using mechanisms such as password, Aadhaar authentication, etc.
  • Personal Identity Data (PID) block captured for Aadhaar authentication should be encrypted during capture and should never be sent in the clear over a network.
  • The encrypted PID block should not be stored unless it is for buffered authentication for a short period, currently configured as 24 hours.
  • Biometric and OTP data captured for the purposes of Aadhaar authentication should not be stored on any permanent storage or database.
  • The meta data and the responses should be logged for audit purposes.
  • Network between AUA and ASA should be secure.

Aadhaar Authentication Documents