1. User Portal
1.1. Device Management
1.2. Aadhaar Services
1.2.1. Auth
1.2.2. Bfd
1.2.3. e-KYC
1.2.4. Demographic Verification
1.3. Reports
1.3.1. Transaction Reports
1.3.2. Demographic Reports
1.3.3. Userwise Transactions Reports
2. e-KYC API: Response Data Format
2.1. <KycRes ret=“” code=“” txn=“” ts=“” ttl=”” actn=”” err=“”> <Rar>base64 encoded fully valid Auth response XML for resident</Rar> <UidData uid=””> <Poi name=“” dob=“” gender=“” phone=“” email=“”/> <Poa co=”” house=”” street=”” lm=”” loc=”” vtc=”” subdist=”” dist=”” state=”” pc=”” po=””/> <LData lang=”” name=”” co=”” house=”” street=”” lm=”” loc=”” vtc=”” subdist=”” dist=”” state=”” pc=”” po=””/> <Pht>base64 encoded JPEG photo of the resident</Pht> </UidData> <Signature /> </KycRes>
3. Types of Services
3.1. OTP_Kyc (OTP Generation for "KYC")
3.2. KYC_OTP(Kyc Transaction with OTP)
3.3. OTP_Auth (OTP Generation for Authentication)
3.4. Auth_OTP (Authentication Transaction with OTP)
3.5. Auth_Bio (Authentication with Biometric i.e ; Iris,fingerprint)
3.6. Auth_Irirs (Authentication with IRIS)
3.7. Kyc_Bio (kyc Transaction with Biometric)
3.8. Kyc_Iris (Kyc Tranasction with Iris)
4. Certificates
4.1. Signer Certificate
4.1.1. With the help of Signer certificate we will Signing the total request format.It is having minimum 2 years.
4.2. Encryption Certificate
4.2.1. Ekyc response data will decrypt by using encryption certificate.It is having minimum 2 years
4.3. UIDAI Auth Certificate (Production,PreProduction)
4.3.1. These are public certificates provided by UIDAI public portal
5. e-KYC API: Input Data Format
5.1. <Kyc ver=“” ts=“” ra=“” rc=“” mec=”” lr=”” de=””> <Rad>base64 encoded fully valid Auth XML for resident</Rad> </Kyc>
5.1.1. RAD: This element contains base64 encoded Auth XML request.
6. Admin Portal
6.1. User Management
6.1.1. Create Users
6.1.2. Lisence Creating and Previliges and active inactive for users
6.2. Lisence Management
6.2.1. Device Whitelist with Multiple MAC id's with Excel
6.2.2. Device Blocking
6.3. Reports
6.3.1. Transaction Reports
6.3.2. Demographic Reports
6.3.3. Userwise Transactions Reports
6.4. Statements
7. OTP Request Format
7.1. <?xml version="1.0" encoding="UTF-8" standalone="yes"?> <Otp uid=”” tid=”” ac=”” sa=”” ver=”” txn=”” lk=””> <Opts ch=””/> <Signature>Digital signature of AUA</Signature> </Otp>
7.1.1. "uid" : (mandatory) Aadhaar Number of the resident
7.1.2. "tid" : (mandatory) For Registered devices, send its unique Terminal ID. For Public devices, value should be passed as “public”
7.1.3. "ac" : (mandatory) A unique code for the AUA which is assigned by UIDAI during AUA registration process. This is an alpha-numeric string having maximum length 10. (A Default value “public” is available only for testing.)
7.1.4. "sa" : (mandatory) A unique “Sub-AUA” code. AUAs are expected to manage these codes within their system and ensure uniqueness within their system. This allows auditing and business intelligence to be provided at SA level. If AUA and SA are same agency, use value of “ac” for this attribute. This is an alpha-numeric string having maximum length 10.
7.1.5. "ver" : (mandatory) version of the OTP API. Currently only valid value is “1.5”.
7.1.6. "txn" : (optional) AUA specific transaction identifier.This was generated by us.
7.1.7. "lk" : (mandatory) A valid “License Key” assigned to the AUA. Administration portal of UIDAI will provide a mechanism for AUA administrator to generate license keys.
7.1.8. "Opts" : (Optional) Various options are provided under this element.
7.1.9. "Signature" : (mandatory) 1. The request XML should be digitally signed for message integrity and non-repudiation purposes. 2. Digital signing should always be performed by the entity that creates the final request XML
8. Authentication Request
8.1. <Auth uid="" rc="" tid="public|registered|mixed" ac="" sa="" ver="" txn="" lk=""> <Uses pi="" pa="" pfa="" bio="" bt="" pin="" otp=""/> <Meta udc="" fdc="" idc="" cdc="" fpmi="" fpmc="" irmi="" irmc="" fdmi="" fdmc="" /> <Skey ci="" ki="">encrypted and encoded session key</Skey> <Data type="X|P">encrypted PID block</Data> <Hmac>SHA-256 Hash of Pid block, encrypted and then encoded</Hmac> <Signature>Digital signature of AUA</Signature> </Auth>
8.1.1. uses : (mandatory) This element specifies the authentication factors used by the request. When an authentication factor is specified in this element, that specific attribute must be present in the encrypted data block. This is particularly useful in situations where the AUA does not fully control the terminal device, but wishes to maintain a certain level of control on the authentication transaction.
8.1.2. meta : This element specifies metadata related to the device and transaction. This is mandatory for better tracking, reporting, and trouble shooting. Additionally see Registered Devices section later in this document.
8.1.3. SKey : Value of this element is base-64 encoded value of encrypted 256-bit AES session key. Session key must be dynamically generated for every transaction (session key must not be reused) and must not be stored anywhere except in memory.
8.1.4. Data : Contains the encrypted “Pid” element in base-64 format. See “Pid” element definition later.
8.1.4.1. <Pid ts="" ver=""> <Demo lang=""> <Pi ms="E|P" mv="" name="" lname="" lmv="" gender="M|F|T" dob="" dobt="V|D|A" age="" phone="" email=""/> <Pa ms="E" co="" house="" street="" lm="" loc="" vtc="" subdist="" dist="" state="" country="" pc="" po=""/> <Pfa ms="E|P" mv="" av="" lav="" lmv=""/> </Demo> <Bios> <Bio type="FMR|FIR|IIR|FID" posh="" bs="">encoded biometric</Bio> </Bios> <Pv otp="" pin=""/> </Pid>
8.1.4.1.1. Demo: Contains child elements “Pi”, “Pa” and “Pfa”, all of which are optional. 1. All demographic data fields as per KYR specifications.
8.1.4.1.2. Bios: This element can have one or many “Bio” elements carrying biometric records to be matched.
8.1.4.1.3. Pv: This element (“Pin Value”) allows support for additional factors “pin” and “otp”.
8.1.5. Hmac : Devices which is constructing the “Pid” element must perform the following to provide the Hmac value: o If Pid type is “X” (XML), then: 1. After forming Pid XML, compute SHA-256 hash of Pid XML string 2. Then encrypt using session key (skey) 3. Then encode using base-64 encoding (as described earlier, encoding can be done on the AUA server when forming final Auth XML)
8.1.6. Signature : (mandatory) 1 The request XML should be digitally signed for message integrity and non-repudiation purposes. 2. Digital signing should always be performed by the entity that creates the final request XML