Introduction
As the number of Aadhaars generated has increased, the focus at many States has
shifted to Aadhaar enablement of service delivery applications. Service providers
who integrate with UIDAI’s platform have to overcome the challenge of linking their
database records of customers and beneficiaries with the 12-digit Aadhaar numbers.
Currently most seeding initiatives are organic and limited in scale because of some
of the challenges listed in the previous section. Further since service delivery
databases are owned by various departments, organic seeding initiatives at a
scheme or department level leads to inconvenience for the resident who is a
beneficiary of multiple services from various departments. Finally there are different
levels of infrastructure/ personnel availability at different states as well as differing
channels and processes being used.
UIDAI has been closely involved in enabling States in implementing Aadhaar
enabled service delivery through a variety of initiatives such as the ICT assistance,
coordinated pilot programs, SRDH software and support etc. Along the same lines,
UIDAI currently proposes to enable service delivery owners in expediting seeding of
their databases by developing and hosting an online platform called the Remote
Aadhaar Seeding Framework (RASF) application.
The RASF application is a central platform that enables converging various seeding
channels into one
central staging area
which is then
accessible to
operators at various
departments (service
delivery owners) for
verification of the
seeding and inclusion
into their service
delivery databases.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 15 of 19
The RASF application aims to provide:
1. Online convergence platform for multiple seeding channels and a ready-made
SMS/ online resident self-service channel for the States usage.
2. Controlled access for department operators to verify seeding by comparing
beneficiary record at the department with the UIDAI resident KYR data from
SRDH web services.
3. MIS, fine grained user access management, audit trails and data
import/export features to enable states to adopt a consistent effective and
efficient approach to multi-channel seeding.
3.2 High Level Features
The key high level features of RASF are:
1. Support multiple Seeding Input Channels
a. SMS-Based seeding
b. Online/ Web-Based seeding
c. CSV maps (SRDH compliant formats from camps/ CSCs/ third party seeders/
state SRDH etc.)
d. All seeding requests irrespective of channel would validate availability of all
mandatory inputs, reject duplicate requests and ensure validity of UID number
through Verhoeff algorithm.
2. Verification Utility
a. Plain vanilla Input Viewer
b. Service Delivery data and/ or SRDH Integrated Viewer
3. Fine grained user access management
4. Audit Trails
5. MIS Reports
a. By service domain or scheme (e.g.: PDS)
b. By Geographic area (e.g.: State or Pincode or District)
c. By User (e.g.: Seeder or Verifier or Admin etc.)
d. By any combination of above
*The RASF will utilize the same pincode master database as the enrolment client does for
geographical master data such as states/ districts/ pincodes/ vtc etc.
*RASF will use HTTPS during data transfer as well as use captcha, OTP and
username/password based access control other than auditing all transactions in order to
appropriately handle security considerations.
3.3 Users and Roles
Fine grained access control is expected to be available wherein access can be restricted by
any combination of (a) application feature, (b) geographic area data constraint (state), (c)
service/ scheme domain (PDS/ MNREGA/ JSY etc.) and (d) read/ write access.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 16 of 19
Five primary types of users are envisaged for the RASF application framework, namely
RASF administrator, State administrators, Seeders, Residents and Verifiers. A brief
overview of the typical user types is as below:
3.3.1 RASF Administrator
The RASF administrator at UIDAI can
1. Create/ Modify/ Delete
a. State Administrators (restricted by State)
b. New service domains (Department-Scheme Master)
2. Generate MIS reports
3. Add/ Remove the State SRDH web service integration detail
3.3.2 State Administrators
The State administrator is typically from the State nodal agency and is the administrator for
the State and can
1. Create/ Modify/ Delete
a. Department Administrators (restricted by Department)
2. Generate MIS reports (for the particular State only)
3.3.3 Department Administrators
The Department administrator is typically from any department in the state and is the
administrator for the Department and can
1. Create/ Modify/ Delete
a. Seeders (can be restricted by service domains and geographical areas)
b. Verifiers (can be restricted by service domains)
2. Upload Department KYR data as CSV
3. Generate MIS reports (for the particular Department only)
3.3.4 Seeders
Seeders are approved for access by the Department administrator and can
1. Upload seeding records in single mode through SMS and Online channels
2. Upload seeding records in batch mode through Excel upload channel
3.3.5 Verifiers
Verifiers are approved for access by the Department administrator and can
1. Accept or reject seeding requests from residents and seeders.
2. See MIS reports of their own usage
3.3.6 Residents
Residents can access RASF only after OTP (one time password) authentication and can
place their KYR+ seeding requests either through the SMS or Online channels only.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 17 of 19
3.4 Business Architecture &Process Flow
RASF is to be hosted at UIDAI. The deployment overview of RASF is as shown below:
The primary process flow as expected for RASF is shown below:
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 18 of 19
Some of the key points to note corresponding to the process flow as shown above are:
1. The RASF admin is from UIDAI and primarily creates the State administrators (step
1) and the master data (step 2). Other than these two activities, UIDAI uses RASF
only for MIS reports. RASF is managed and used by the State administrators
and other users.
2. States can onboard third party seeders (step 4) to conduct camps/ door to door
campaigns etc. The seeders can then upload seeding requests to RASF. This is
similar to registrars using enrolment agencies for Aadhaar enrolments.
3. SRDH enables verifiers to view UID KYR record for a given seeding request. SRDH
is typically deployed at the State and not by UIDAI. Hence it is the State
administrators’ responsibility to provide the web service details of SRDH as
configuration details to the RASF administrator. Note that SRDH is not necessary
(i.e. verification screen will work without SRDH; this is allowed since verifier might
have access to UID KYR data through some other application outside RASF) but is
highly recommended.
4. A seeding request can come from any channel and consists of a mapping of
Aadhaar number and beneficiary ID (steps 5a or 5b). Seeding requests can be in
single mode (SMS or online request) or batch mode (CSV upload by seeder).
RASF will have pre-determined CSV input format which will be aligned with the
SRDH manual and batch seeding CSV formats. This enables the SRDH user at
the State to upload the CSV to RASF for verification as a seeder.
5. RASF will also highlight to the seeder at the time of seeding request itself (steps
5a and 5b) if one or more of the requests are already accepted valid seeding
from other requests. This requires that RASF always stores the basic request map
even after acceptance by verifiers.
6. Verifiers can compare the UID KYR record to the department KYR record for
verification. Note that SRDH view is available within RASF if the web service is
configured by state admin. It is also possible that the verifier uses SRDH outside
RASF. Similarly the department KYR view is available within RASF if the department
admin has uploaded the department data as CSV. It is again possible that the
verifier uses some other application outside RASF to access and view
department KYR records.
7. Note that after verification, verifiers can export the valid accepted maps as CSV. This
ensures that RASF requires no integration to various service delivery
databases.
8. It is recommended that verifiers are from the service departments (or trusted
third parties chosen by the respective departments) since this creates ownership
of the seeding.
9. It needs to be noted that most of the current challenges faced by seeding initiatives
can be overcome by careful choice of seeding channels. However each seeding
channel has its own pros and cons. For example departmental data in local language
data is a significant issue in inorganic seeding but however is not a hurdle for organic
seeding where the verifier is competent in the local language.
10. UIDAI provides RASF only as an enabling tool for seeding efforts and it is not meant
to replace any existing or envisaged efforts. UIDAI intends to improve RASF and
provide iterations in the near future.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 19 of 19
3.5 Conclusion
A multi-channel convergence approach to seeding can help overcome current
challenges and importantly scale seeding efforts significantly where each channels’
weakness is compensated by usage of other channels. Further since seeding inherently
requires manual comparison of data is most cases, it is important to enable a large
number of verifiers in the ecosystem to be able to work in a coordinated fashion to
effectively scale operations. RASF aims to provide a consistent process oriented
approach to large scale multichannel seeding and hopes to expedite Aadhaar seeding
across the nation.
As the number of Aadhaars generated has increased, the focus at many States has
shifted to Aadhaar enablement of service delivery applications. Service providers
who integrate with UIDAI’s platform have to overcome the challenge of linking their
database records of customers and beneficiaries with the 12-digit Aadhaar numbers.
Currently most seeding initiatives are organic and limited in scale because of some
of the challenges listed in the previous section. Further since service delivery
databases are owned by various departments, organic seeding initiatives at a
scheme or department level leads to inconvenience for the resident who is a
beneficiary of multiple services from various departments. Finally there are different
levels of infrastructure/ personnel availability at different states as well as differing
channels and processes being used.
UIDAI has been closely involved in enabling States in implementing Aadhaar
enabled service delivery through a variety of initiatives such as the ICT assistance,
coordinated pilot programs, SRDH software and support etc. Along the same lines,
UIDAI currently proposes to enable service delivery owners in expediting seeding of
their databases by developing and hosting an online platform called the Remote
Aadhaar Seeding Framework (RASF) application.
The RASF application is a central platform that enables converging various seeding
channels into one
central staging area
which is then
accessible to
operators at various
departments (service
delivery owners) for
verification of the
seeding and inclusion
into their service
delivery databases.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 15 of 19
The RASF application aims to provide:
1. Online convergence platform for multiple seeding channels and a ready-made
SMS/ online resident self-service channel for the States usage.
2. Controlled access for department operators to verify seeding by comparing
beneficiary record at the department with the UIDAI resident KYR data from
SRDH web services.
3. MIS, fine grained user access management, audit trails and data
import/export features to enable states to adopt a consistent effective and
efficient approach to multi-channel seeding.
3.2 High Level Features
The key high level features of RASF are:
1. Support multiple Seeding Input Channels
a. SMS-Based seeding
b. Online/ Web-Based seeding
c. CSV maps (SRDH compliant formats from camps/ CSCs/ third party seeders/
state SRDH etc.)
d. All seeding requests irrespective of channel would validate availability of all
mandatory inputs, reject duplicate requests and ensure validity of UID number
through Verhoeff algorithm.
2. Verification Utility
a. Plain vanilla Input Viewer
b. Service Delivery data and/ or SRDH Integrated Viewer
3. Fine grained user access management
4. Audit Trails
5. MIS Reports
a. By service domain or scheme (e.g.: PDS)
b. By Geographic area (e.g.: State or Pincode or District)
c. By User (e.g.: Seeder or Verifier or Admin etc.)
d. By any combination of above
*The RASF will utilize the same pincode master database as the enrolment client does for
geographical master data such as states/ districts/ pincodes/ vtc etc.
*RASF will use HTTPS during data transfer as well as use captcha, OTP and
username/password based access control other than auditing all transactions in order to
appropriately handle security considerations.
3.3 Users and Roles
Fine grained access control is expected to be available wherein access can be restricted by
any combination of (a) application feature, (b) geographic area data constraint (state), (c)
service/ scheme domain (PDS/ MNREGA/ JSY etc.) and (d) read/ write access.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 16 of 19
Five primary types of users are envisaged for the RASF application framework, namely
RASF administrator, State administrators, Seeders, Residents and Verifiers. A brief
overview of the typical user types is as below:
3.3.1 RASF Administrator
The RASF administrator at UIDAI can
1. Create/ Modify/ Delete
a. State Administrators (restricted by State)
b. New service domains (Department-Scheme Master)
2. Generate MIS reports
3. Add/ Remove the State SRDH web service integration detail
3.3.2 State Administrators
The State administrator is typically from the State nodal agency and is the administrator for
the State and can
1. Create/ Modify/ Delete
a. Department Administrators (restricted by Department)
2. Generate MIS reports (for the particular State only)
3.3.3 Department Administrators
The Department administrator is typically from any department in the state and is the
administrator for the Department and can
1. Create/ Modify/ Delete
a. Seeders (can be restricted by service domains and geographical areas)
b. Verifiers (can be restricted by service domains)
2. Upload Department KYR data as CSV
3. Generate MIS reports (for the particular Department only)
3.3.4 Seeders
Seeders are approved for access by the Department administrator and can
1. Upload seeding records in single mode through SMS and Online channels
2. Upload seeding records in batch mode through Excel upload channel
3.3.5 Verifiers
Verifiers are approved for access by the Department administrator and can
1. Accept or reject seeding requests from residents and seeders.
2. See MIS reports of their own usage
3.3.6 Residents
Residents can access RASF only after OTP (one time password) authentication and can
place their KYR+ seeding requests either through the SMS or Online channels only.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 17 of 19
3.4 Business Architecture &Process Flow
RASF is to be hosted at UIDAI. The deployment overview of RASF is as shown below:
The primary process flow as expected for RASF is shown below:
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 18 of 19
Some of the key points to note corresponding to the process flow as shown above are:
1. The RASF admin is from UIDAI and primarily creates the State administrators (step
1) and the master data (step 2). Other than these two activities, UIDAI uses RASF
only for MIS reports. RASF is managed and used by the State administrators
and other users.
2. States can onboard third party seeders (step 4) to conduct camps/ door to door
campaigns etc. The seeders can then upload seeding requests to RASF. This is
similar to registrars using enrolment agencies for Aadhaar enrolments.
3. SRDH enables verifiers to view UID KYR record for a given seeding request. SRDH
is typically deployed at the State and not by UIDAI. Hence it is the State
administrators’ responsibility to provide the web service details of SRDH as
configuration details to the RASF administrator. Note that SRDH is not necessary
(i.e. verification screen will work without SRDH; this is allowed since verifier might
have access to UID KYR data through some other application outside RASF) but is
highly recommended.
4. A seeding request can come from any channel and consists of a mapping of
Aadhaar number and beneficiary ID (steps 5a or 5b). Seeding requests can be in
single mode (SMS or online request) or batch mode (CSV upload by seeder).
RASF will have pre-determined CSV input format which will be aligned with the
SRDH manual and batch seeding CSV formats. This enables the SRDH user at
the State to upload the CSV to RASF for verification as a seeder.
5. RASF will also highlight to the seeder at the time of seeding request itself (steps
5a and 5b) if one or more of the requests are already accepted valid seeding
from other requests. This requires that RASF always stores the basic request map
even after acceptance by verifiers.
6. Verifiers can compare the UID KYR record to the department KYR record for
verification. Note that SRDH view is available within RASF if the web service is
configured by state admin. It is also possible that the verifier uses SRDH outside
RASF. Similarly the department KYR view is available within RASF if the department
admin has uploaded the department data as CSV. It is again possible that the
verifier uses some other application outside RASF to access and view
department KYR records.
7. Note that after verification, verifiers can export the valid accepted maps as CSV. This
ensures that RASF requires no integration to various service delivery
databases.
8. It is recommended that verifiers are from the service departments (or trusted
third parties chosen by the respective departments) since this creates ownership
of the seeding.
9. It needs to be noted that most of the current challenges faced by seeding initiatives
can be overcome by careful choice of seeding channels. However each seeding
channel has its own pros and cons. For example departmental data in local language
data is a significant issue in inorganic seeding but however is not a hurdle for organic
seeding where the verifier is competent in the local language.
10. UIDAI provides RASF only as an enabling tool for seeding efforts and it is not meant
to replace any existing or envisaged efforts. UIDAI intends to improve RASF and
provide iterations in the near future.
UIDAI – RASF – Introduction Document
Copyrights © 2012. All rights reserved. Page 19 of 19
3.5 Conclusion
A multi-channel convergence approach to seeding can help overcome current
challenges and importantly scale seeding efforts significantly where each channels’
weakness is compensated by usage of other channels. Further since seeding inherently
requires manual comparison of data is most cases, it is important to enable a large
number of verifiers in the ecosystem to be able to work in a coordinated fashion to
effectively scale operations. RASF aims to provide a consistent process oriented
approach to large scale multichannel seeding and hopes to expedite Aadhaar seeding
across the nation.
No comments:
Post a Comment