uidai - srdh - state adoption strategy

7/25/2019 UIDAI - SRDH - State Adoption Strategy

http://slidepdf.com/reader/full/uidai-srdh-state-adoption-strategy 1/33

© 2012 All rights reserved. of 33

State Resident Data Hub

(SRDH)

State Adoption Strategy Document

v1.2

March, 2012



)

UIDAI – SRDH – State Adoption Strategy Document


!is page !as been intentiona""y "e#t b"an$.





ab"e o# %ontents

1 Introduction to t!e Document ...................................................................................... &

1.1 Purpose of the Document ............................................................................................ 9

1.2 Target Audience .......................................................................................................... 9

2 Introduction to SRDH App"ication 'rameor$ ..........................................................1

2.1 !"ectives of #$D% ....................................................................................................10

2.2 #ummar& on #$D% ....................................................................................................10

2.3 'enefits of #$D% ........................................................................................................12

*

SRDH App"ication 'rameor$+s State Adoption Strategy ........................................1,

3.1 #$D% Data Availa!ilit& ...............................................................................................1(

3.1.1 nrolment Data ....................................................................................................1(

3.1.2 *h& onl& +,$ ......................................................................................................1(

3.1.3 Data #ources .......................................................................................................1-

3.1. Data Availa!ilit& and /change ............................................................................1-

3.2 #$D% Data ntegrit& ...................................................................................................19

3.2.1 AA #ervices .......................................................................................................19

3.2.2

+eeping Data p to Date .....................................................................................20

3.2.3 +e& essages to $esidents .................................................................................21

3.3 sage of #$D% ..........................................................................................................21

3.3.1 #eeding4 or Aadhaar #eeding4 ............................................................................21

3.3.2 Data 5leaning ......................................................................................................22

3.3.3 #tarting up 6ith clean +,$ data...........................................................................23

3.3. Access 5ontrol .....................................................................................................23

3. perating #$D% at #tate ............................................................................................2

,

Appendi- ......................................................................................................................2

.1 7unctions of #$D% .....................................................................................................2(

.2 8odal Agenc& as an AA ............................................................................................30

.2.1 ntroduction ..........................................................................................................30

.2.2 AA $eadiness #tages .......................................................................................30

.2.3 +e& AA $esponsi!ilities.....................................................................................31



)


© 2012 All rights reserved. Page of 33

.2. andator& #ecurit& $euirements .......................................................................32

// 0D ' D%U30 // .......................................................................................................*2



)


© 2012 All rights reserved. Page ( of 33




)


© 2012 All rights reserved. Page - of 33

Document History

4ersion Aut!or Remar$s Re"ease Date

1.0 :ive; #ingh 8<A 10<02<2012

1.1 :ive; #ingh $evising !asis ne6 discussions6ith DA P

1<03<2012

1.2 #u!ramaniam:aid&anathan

inor pdates and 5leanup 2-<03<2012

1.3

1.

1.(

1.-

1.=

1.>

1.9

2.0



)


© 2012 All rights reserved. Page = of 33

Document 3etadata

it"e #tate #$D% Adoption #trateg& document

Sub5ect 6

7eyords

• #$D% #tate Adoption anagement #trategies

• #tate4s #$D% Development and $oll out Plans

• ?everaging #$D% in a #tate

Source • #$D% 7$# and #$#

• #$D% Pro"ect Plan

• DA P Discussions

• #$D% Product anagement #trateg& document

Description #$D% Adoption #trateg& document is primaril& meant for #tates that intend

to understand@ prepare for and deplo& #$D%.

t aims to provide DA 6ith operational guidance on ho6 to prepare for@

deplo& and manage its o6n #tate $esident Data %u! #$D%) #oft6are

application.

%overage #$D% Adoption #trateg& document is applica!le for the entire product

lifec&cle of #$D% 6ithin a #tate.

ype perating Buidelines

%reator #$D% 5onsultant

%ontributor • DA P

• #$D% ##P

8ub"is!er DA

Rig!ts DA9anguage nglish

'ormat # *ord<Ado!e Acro!at PD7

Date 2- arch@ 2012



)


© 2012 All rights reserved. Page > of 33

9ist o# Important Acronyms

Item Description

AA Authentication ser Agenc&#$D% #tate $esident Data %u!

##P #oft6are #olution Provider

DA niue dentification Authorit& of ndia

P Program anagement nit

+,$ +no6 ,our $esident

5D$ 5entral dentities Data $epositor&

D5<#D5 Data 5enter<#tate Data 5enter

AT ser Acceptance Testing

Po5 Proof of 5oncept

$s $egional ffices of DA in #tates)

#$P #tate $esource Person?DAP ?ight6eight Director& Access Protocol

D nrolment D

AP Application Programming nterface

DB Director Beneral

DDB Deput& Director Beneral

ADB Assistant Director Beneral

5$P 5onference $oom Pilot

CA Cualit& Assurance

#P5 #ingle Point of 5ontact

8P$ 8ational Population $egister

#A# #tate Aadhaar ntegrated #&stem

5## 5entralied ntegrated #&stem for #tate##DB #tate #ervice Deliver& Bate6a& ##DB)

AP# Aadhaar na!led Pa&ment #&stem

A Aadhaar ntegration odule

'P? 'elo6 Povert& ?ine

5#: 5omma #eparated :alues

P$ ntellectual Propert& $ights

#o* #cope<#tatement of *or;

5$ 5hange $euest

:P8 :irtual Private 8et6or;# #&stems ntegrator

%# %ard6are #ecurit& oduleP# Point of #ervice



)



1 Introduction to the Document

1.1 Purpose of the Document

• The SRDH State Adoption Strategy document is a value proposition document for

#$D%@ developed for the soonEtoE!e or future #$D% o6ners@ 6hich provides adoption

strategies for successful deplo&ment of #$D%

• This document primaril& aims to provide the #tates 6ith ena!ling levers to adopt #$D%

• The document is essentiall& recommendator& in nature@ though there could !e areas@

6here securit& of D and +,$ data is paramount@ that it ma& attempt to mandate

• The document does not provide technical installation procedures and issue resolution

methods

1.2 Target Audience

The intended audience for this document isF

• Appointed #$D% #tate 8odal fficers and<or D $egistrars

• T #ecretaries of #tates

• Departmental %eads of #tates

• #tate4s T department team<selected # vendor



)



2 Introduction to SRDH Application Framewor

2.1 !"#ecti$es of SRDH

The #$D% aims toF

• anage complete #tate level $esident Data in a Digitied@ 5entralied and #ecure

manner

• nhance Aadhaar Data #ecurit&

• ?everage $esident Data in #ervice Deliver& Applications

• asil& incorporate Aadhaar authentication into various applications

A detailed overvie6 of functions of #$D% has !een provided in theSection 4: Appendix of this

document. t is highl& recommended that readers of this document go through that information

on #$D%.

2.2 Summar% on SRDH

The overall conte/t and scope of the #$D% initiative is descri!ed !elo6F

• The #tate $esident Data %u! #$D%) Application 7rame6or; is e/pected to ena!le the

states to !uild a clean master data!ase of stateEspecific residents 6hose details shall !e

derived from the Aadhaar enrolment data. This should provide the platform to allo6

#tates toF 1) !uild a master data!ase of clean@ authentic and upEtoEdate resident details

using the +,$ data as gathering during the Aadhaar enrolment process@ and 2) 6eed

out duplicate and fa;e resident records that could !e e/isting in various state

governmental data!ases and s&stems@ and potentiall& siloEd setup.

• The deplo&ment of the #$D% Application 7rame6or; in the state data centers 6ould

create an infrastructure for states to manage their o6n data@ starting 6ith the Aadhaar

enrolment data as the !ase. The various departments in the #tate and T are e/pected

to access this data store via 6ellEdefined AP<s and then perform residentEdataE

enrichment as needed.

• The #$D% Application 7rame6or; 6ould also allo6 for secure 6rapper services for

accessing the resident information via clearl& defined $'A5 $ole 'ased Access

5ontrol). These 6rapper services shall also ena!le search and update of residentrecords !& e/act < partial match.

• The #$D% Application 7rame6or; 6ould provide a !asic vie6 of the resident t&picall&

+,$ information as captured during the Aadhaar enrolment)G and also allo6 for the

#tateEspecific department data!ases to connect and access the same.

• The #$D% Application 7rame6or; 6ould provide seeding utilities that allo6 users to

map e/isting +,$ euivalent data in departments to clean +,$ records as in #$D% in



H



an interactive semiEautomated manner to ena!le the seeding of Aadhaar num!ers into

#tateEspecific department data!ases.

• The #$D% Application 7rame6or; 6ould readil& support Aadhaar Authentication using

Authentication AP such that #tates ma& adopt Aadhaar Authentication into theirapplications 6ith minimalistic configuration changes.

• Provide reporting capa!ilities in terms of metrics that provide a snapshot of the health

and performance of #$D%.

• The #$D% application frame6or; provides for a !asic uer& !uilder that allo6s technical

users to uer& remote departmental data!ases@ persist the resulting data temporaril& in

#$D% and then allo6 users to crossEuer& across #$D% and the persisted

departmental data. This allo6s users to plan for 6elfare schemes since !eneficiar&

entitlement criteria are t&picall& spread across multiple departments currentl&.

• ?astl&@ the #$D% Application 7rame6or; 6ould also !e a!le to push DED files and

pac;ets !oth 'iometric and +,$I) onto the DA :ault4G thus ma;ing the data lessprone to theft and a!use.

5onceptual flo6 of data is as sho6n !elo6F

A more detailed process flo6 is depicted !elo6F





2.& 'enefits of SRDH

Deplo&ing #$D% provides a #tate 6ithF

• :alid demographic data that is 5D$ verified

• pportunit& to use thisF

o demographic data containing Aadhaar num!ers) for #eeding various #tate

application data!ases 6ith Aadhaar num!er

o demographic data and clean up its o6n applications4 data!ases

• ?egitimate $esident data accessi!le to #tates4 applications J the much sought after

Aadhaar integration !ecomes a realit&

• utEofEtheE!o/ AA #erver #oft6are to e/pedite implementation of Aadhaarauthentication for #tate applications

• A!ilit& to !etter manage the fund dis!ursement and social 6elfare < financial inclusion

schemes

perational guidelines and related details on ho6 to ta;e up #$D% deplo&ments and !e a!le to

reap the a!ove listed !enefits have !een provided in the follo6ing sections.



)



SRDH Adoption Strategy #or

State



)


© 2012 All rights reserved. Page 1 of 33

& SRDH Application Framewor(s State Adoption Strateg%

The #$D% Application 7rame6or;4s #tate Adoption #trateg& provides ndian #tates 6ith a

holistic vie6 and operational guidelines on ho6 to deplo&@ manage and operationalie #$D%.

The follo6ing su!sections 6ould primaril& tal; a!outF

• n the ground practices and roadmap to prepare for@ deplo& and manage #$D%

• Procedure to !ecome an AA

• T&pical #$D% usage scenarios to leverage #$D% !enefits

o #eeding

o AA services

o +,$ and<or #$D% Data updation

o 'usiness case scenarios• $esident data acuisition approaches

• +,$ and D<demographic data sharing procedure

• Deplo&ment $is;s

• #$D% Application 7rame6or; customiations

• 5hange $euest anagement

• *arrant& and #upport

• ?ocal language support in!uilt 6ith #$D%

• #$D% relevant infrastructure and personnel readiness

• Bovernance and o6nership of #$D%

• #$D% Product training and sensitiation 6or;shops• 5olla!oration 6ith other #tate departments



)


© 2012 All rights reserved. Page 1( of 33

&.1 SRDH Data A$aila"ilit%

&.1.1 )nrolment Data

The DA < Aadhaar nrolment Data come from various sources and in different forms. t is

important to understand these as that 6ill give adeuate insight on data management in #$D%.

ature o# Data 8ac$ets 7:R; Database 'i"es 0ID<UID =39 'i"es

Demograp!ic

In#ormation (7:R)

>iometrics

('ingerprints and Iris)

8!otograp!

ost $egistrars have not

captured photo in +,$I)

Possi!le to include

photograph)

0ID

UID

7:R; In#ormation

Secure (8assord ?

0ncryption)

&.1.2 *h% onl% +,R

DA is providing #$D% Application 7rame6or; to #tates@ 6hich uses various methods to

collate and maintain +,$ data of #tate residents into a single data!ase. Three such methods

areF

1. DED mapping files@ provided to registrars 6ho enroll residents@ and 6ho update

resident data

2. rganic anual) data Addition < pdate !& #$D% !usiness users. This is onl& done

after authentication of data against 5D$ data.

3. rganic anual) data Addition < pdate !& #tate residents also ;no6n as $esident #elf

#ervice. This is onl& done after authentication of data against 5D$ data.

'& default@ all data 6hich ma& !e included in #$D% trough one of the methods a!ove is +,$

data@ as defined in Aadhaar enrollments. +,$I data fields Program dentifiers) such as $ation

5ard 8um!er@ B8$B# Ko! 5ard 8um!er@ and Driving ?icense 8um!er etc. have not !een

included consciousl& in #$D%. The reason is that various departments 6hich manage

program<scheme data ma& simpl& seed their !eneficiar&<resident data 6ith Aadhaar num!er@

6hich ena!les a logical lin;ing. f #$D% 6ere to also maintain all Program identifiers also@ it 6ill



)


© 2012 All rights reserved. Page 1- of 33

!e duplication of data@ 6hich results in pro!lems of s&nchroniation and o!solete data. nsuring

a singleEsourceEofEtruth on resident data helps in !etter management of the data.

%o6ever@ #tates ma& ta;e a decision to add more fields in #$D%@ if the& strongl& feel the need

to do so. The same ma& !e achieved !& #tate4s T team or #&stem ntegrator.7inall&@ #$D% is intended to provide access to +,$ data to #tate departments. Authentication

should !e carried out against the 5D$ data!ase of DA using the authentication frame6or;

introduced later in this document. %ence #$D% does not need to and should not) store

!iometric data.

&.1.& Data Sources

#ufficient +,$ data is the cornerstone of #$D% functions. A #tate must have access to +,$

data of its $esidents for a successful launch of #$D%.

#$D% Data !asicall& comprises of +,$ data along 6ith D< D num!ers and citien

photograph. The relevant ro6s from the enrolment data ta!les as in previous section areF

ature o# Data 8ac$ets 7:R; Database 'i"es 0ID<UID =39 'i"es

Demograp!ic

In#ormation (7:R)

UID

The +,$ data collected during nrolments as in Pac;ets does not &et have the D num!ers.nce the D num!ers are generated the& are pu!lished !& DA on the Portal accessi!le

onl& to $egistrars) in the form of EID!ID "M# $i%e&. These H? files 6ill ver& soon !e

encr&pted and also carr& the photograph. #$D% is designed to support !oth unencr&pted and

encr&pted DED H? files 6ith or 6ithout photographs.

8ote that the earliest generation of DED H? files pu!lished !& DA carried onl& D and

D num!ers and did not have an& +,$ data@ these files are not usa!le in #$D% since +,$

data is the core of #$D%.

&.1.- Data A$aila"ilit% and )change

The DED files pu!lished !& DA are availa!le to registrars through the registrar portal.

5urrentl&@ DA is constrained !& the e/isting data polic& to onl& pu!lish +$, records of those

enrolled !& the particular registrar in the DED file sent to the registrar. This constraint leads

to various issuesF



)


© 2012 All rights reserved. Page 1= of 33

E 5itien +,$ records are hence distri!uted across various registrars. These registrars could !e

#tate or nonE#tate registrars and for a minorit& of cases 6ould also !e registrars 6ho are

operating in a different #tate.

E An& given DED file could contain +,$ records of individuals 6ho is a citien of a different#tate.

E 5ollation attempts of +,$ data for a #tate 6ould hence reuire transfer of DED files across

registrars and hence securit& of data needs to !e considered.

The #tate should !ear in mind the a!ove complications and put in place mechanisms to collate

resident +,$ data in #$D%. ultiple strategies 6ould need to !e in place such as !elo6F

See$ing Data #rom Registrars@

• UIDAI Data S!aring 8o"icyF 5urrentl&@ as per the DA Data #haring Polic&@ Aadhaar

+,$) data collected during nrolments are pu!lished on the DA Portal and allo6s a

$egistrar to access 9: its on +,$ data J hence@ a #tate $egistrar cannot access

data enrolled !& 8on #tate $egistrars.

DA is currentl& revie6ing this Data #haring Polic& and considering necessar&

updates) so that +,$ data of all #tate residents can !e made availa!le to the #tate

$egistrar. *hile an& such Polic& change !ecomes effective@ the #tate should plan

alternative strategies.

• 3emorandum o# Understanding (3oU)@ ne such alternative strateg& could !e for a

#tate to have a o signed 6ith the 8onE#tate $egistrars that 6ould allo6 the 8on

#tate $egistrars to share 6ith #tate $egistrar all their +,$ data captured during theenrolments.

• In#orma" Agreements ? Understanding@ #tate should tr& and discuss to form informal

agreements that could help them o!tain the 8on #tate $egistrar Data.

See$ing Data #rom Residents

Data can !e sought from $esidents in the follo6ing 6a&sF

•

Resident Se"# Serviceo #$D% $esident #elfE#ervice Portal J in!uilt in #$D% Application 7rame6or;

!eing provided !& DA). This 6ould allo6 direct pdate !& the $esident in

#$D% after 5D$ Authentication. #tate could consider e/posing this functionalit&

of the #$D% application through #tate Portals.

• Resident – Assisted

o #$D% application users either from nodal agenc& or approved departmental

users 6ith appropriate access can capture +,$ data from residents and insert<



)


© 2012 All rights reserved. Page 1> of 33

update the same into the #$D% data!ase through the organic manual) insert

functionalit& currentl& availa!le in the #$D% application 6hich appropriatel& first

authenticates data 6ith 5D$ automaticall&. This could !e done atF

o ouc!<points (8oint o# Service < 8S) $esidents ma& 6al;Ein 6ith latest Aadhaar Data < ?etter to 5itien #ervice 5enters 5#5) net6or;s or other points

of service.

o Data Update reuest by 8!ysica" 8ost. The resident ma& post a cop& of their

Aadhaar ?etter to the 8odal Department managing #$D%. The Application user

ma& use the data to ma;e the update.

o Speci#ic Data %o""ection %amps@ The #$D% nodal agenc& could conduct

specific data collection camps or 6or; 6ith departments 6ho might conduct

camps specificall& for their scheme 6here +,$ data can !e collected from

residents and inserted< updated in #$D% through the organic insert< update

functionalities.

State '&( )on State Re&ident& Data

As earlier discussed in this su! section@ DA follo6s a multiEregistrar approach for

enrollments@ 6hich results in #tate enrolling $esidents 6ho !elong to other #tates@ as 6ell as

other $egistrars@ including 'an;s and other #tates@ enrolling $esidents of a particular #tate.

#$D% 8odal Department in a #tate ma& 6ant to maintain data of onl& its $esidents in the #tate

#$D% instance. The #$D% Application 7rame6or; provided !& DA has an option to

selectivel& ;eep data of #tate $esidents4 onl&. There4s a configura!le L#6itchM in #$D% 6hichallo6s the #$D% user to load +,$ data for onl& #tate $esidents from DED files 6hich

contain residents of multiple states. Alternativel&@ the #$D% user ma& choose to load all of the

+,$ data provided and then selectivel& fetch@ through the L#earchM feature to find all 8on #tate

$esidents and LDeactivateM their records.

7or a $esident4s !ac;ground@ the follo6ing definition holdsF

• #tate $esident J An& resident 6hose Aadhaar data has the corresponding #tate name

in the #tate4 field of address.

• 8onE#tate $esident J An& resident 6hose Aadhaar data has an& other #tate name in

the #tate4 field of address

Secure *ran&$er o$ Data +eteen State and )on State Regi&trar& u&ing a Secure !ti%ity

A #tate is strongl& advised to have adeuate #ecurit& mechanisms for data e/change@ to avoid

compromise of sensitive $esident information. n vie6 of this@ it is recommended a #tate

o!taining DED files from multiple registrars or sending DED files to other entities al6a&s

do so 6ith appropriate encr&ption.



)



&.2 SRDH Data Integrit%

#$D% dataset for a #tate is conceptualied as a su!set of 5D$ data. t is critical that all efforts

!e ta;en to ensure that data in #$D% is in s&nc 6ith 5D$ 6hich in turn 6ill provide the

necessar& assurance of data integrit&. n that conte/t@ #$D% has !uilt in functionalit& to autoE

authenticate data 6ith 5D$ at all points of insert< update such as from DED files@ organic

insert< update and $esident #elf #ervice insert< update functionalities.

The AAEA#A Authentication ser Agenc&EAuthentication #ervice Agenc&) frame6or;

designed !& DA to help implement Aadhaar authentication is to !e leveraged !& #$D%. n

that conte/t@ it is highl& recommended that the nodal agenc& at the #tate for #$D% also operate

as the AA for the #tate and could either !e an A#A or leverage an& e/isting A#A.

5urrentl& man& #tates have a large num!er of unencr&pted DED files and the Aadhaarauthentication frame6or; is not &et setup at the #tate. +eeping this in mind@ #$D% can !e

configured during deplo&ment to s6itch off44 authentication for data inserted< updated from DE

D files. This 6ould allo6 #tates to e/pedite loading #$D% 6ith +,$ data at the ;no6n ris; of

loading data that might not have !een sourced from 5D$. This can ho6ever !e handled !& the

#tate at a later date once the authentication frame6or; is in place !& leveraging the

authenticate e/isting records4 functionalit& of #$D%.

t is highl& recommended that organic insert< update as 6ell as resident self service not !e used

6ithout authentication frame6or; first !eing implemented in the #tate. This 6ould ensure that

an& manual entr& 6hether !& residents or #$D% !usiness users is al6a&s first authenticated

6ith 5D$ as the pro!a!ilit& of error in manuall& entered data 6ill !e ver& high.

&.2.1 A/A Ser$ices

#$D% 6ill function as an AA and 6ill route all authentication reuests from registered

departmental applications to 5D$ and !ac;. *hile the 8odal Department for #$D% in a #tate

could !e an AA@ the other departments 6hich 6ould route their Authentication $euests

through the #$D% AA server could !e #u!EAA4s. A classic case of such a deplo&ment is

demonstrated !elo6 6here the T Department in the #tate is the 8odal Department for #$D%

and also the AA)@ and other departments such as 7ood N 5ivil #upplies@ #ocial *elfare@ $ural

Development and ducation are routing their authentication reuests.



)



8ote that #$D% application also leverages the AA services for organic insert< update@ resident

self service and DED file insert functionalities.

#ince the DA authentication frame6or; is out of the scope of #$D% and is an independent

initiative@ it is highl& recommended that the #tate familiarie themselves 6ith the same as

availa!le at 666.uidai.gov.in<auth. inimal relevant details of the authentication frame6or; are

provided in the Appendi/.

&.2.2 +eeping Data /p to Date

ost of the !asic +,$ information of a $esident does not change over time. %o6ever@ data li;e

?ast 8ame@ Address@ Phone 8o. etc. often undergo change due to marriage@ movement to other

to6ns<cities etc.

An& change to +,$ data needs to !e first done at 5D$. This is currentl& ena!led through

various proposed channels as part of the 5D$ updation strateg& pro"ect.

t is important that #$D% data is maintained upEtoEdate so that actual !enefits for the #tate

8odal Department and all Departments 6hich 6ould use the services of #$D% !e relia!le.



OP



An& change in +,$ data at 5D$ is pu!lished !& DA as an PDAT84 record in DED

H? files. This file ho6ever is pu!lished onl& to the registrar to 6hom the resident provided the

updated details. This registrar could !e a nonEstate registrar or even a registrar operating in

another #tate. %ence the same issues and strategies as alread& detailed in section on Data Availa!ilit& and /change4 previousl& in this document 6ould appl&.

&.2.& +e% 0essages to Residents

$esidents have an important role to pla&. The #tates should communicate the follo6ing

approach to residents so that residents are ena!led to participate in ;eeping their data upEtoE

date in #$D%. The messages ma& !e communicated to residents through 8e6spaper

advertisements@ T:<$adio "ingles@ etc.

• Update data in %IDR@ *henever@ there is a change in resident data@ such as 8ame

5hange@ Address 5hange or o!ile 8um!er 5hange@ residents must al6a&s use one of

the pdate channels opened !& DA to update their data in 5D$. The t6o most

common channels for doing so are the permanent pdate<nrollment 5enters and the

#elfE#ervice pdate Portals of DA. Details 6ould !e availa!le on the DA 6e!site

666.uidai.gov.in) in due course of time@ 6hen DA rolls out pdate services.

• Update data in SRDH@ #$D% 6ould have a resident portal for addition of data and

update of data. nce the resident4s data in updated in 5D$@ the residents should !e

encouraged to update their data in #$D% as 6ell. This data ma& !e updated !& the

residents directl& through an& of the other channels opened up !& the #tate.

&.& /sage of SRDH

The ;e& usage of #tate resident +,$ data in #$D% is !& the various #tate departments for

#eeding4 and 5leaning4 of departmental data!ases.

&.&.1 Seeding( or Aadhaar Seeding(

#eeding is the process of lin;ing inserting) Aadhaar num!er in a program<scheme<department

data!ase. 7or e/ample E seeding of Aadhaar num!er in $ation 5ard data!ase is maintained !&7ood N 5ivil #upplies department of the #tate.

t is critical that department< scheme data!ases are seeded 6ith Aadhaar num!ers in order to

identif& individual !eneficiaries 6hich in turn sets up readiness for Aadhaar ena!led service

deliver&@ !oth Aadhaar na!led Pa&ment #ervices AP#) as 6ell as Aadhaar Authentication.



OQ



The #$D% application has in !uilt seeding utilities to ena!le the same. anual seeding feature

of #$D% can !e used 6herein the mapping !et6een department< scheme !eneficiar& D such

as "o! card num!er in 8$BA or $ation 5ard 8um!etr in PD#) and D Aadhaar num!er) is

;no6n or can !e discovered !& the #$D% user through search functionalities of #$D%application. This functionalit& allo6s the departmental user to do6nload the #$D% +,$ data for

these !eneficiaries in 5#: format.

'atch seeding feature of #$D% is a semiEautomated version of the manual seeding feature

6hich reduces the tediousness of having to do manual searches. #$D% users can upload a

5#: of a preEdetermined format< template) containing departmental data +,$ euivalent data

currentl& in Department). The #$D% application processes the input 5#: searches for input

records against #$D% data!ase) and provides an interactive feature 6hich allo6s the #$D%

user to map the input !eneficiar& record against D num!ers in #$D%. After the inetarctive

mapping process is completed@ the user can do6nload the #$D% +,$ data for the mapped

!eneficiaries in 5#: format.

n !oth the a!ove cases@ the do6nloaded information can no6 !e used !& the department for

seeding their o6n data!ases. The same information can also !e used for cleaning the +,$ data

currentl& in department as e/plained in !elo6 section.

t is also possi!le that Departmental soft6are applications can leverage the 6e! services

e/posed !& #$D% to seed their data!ases.

&.&.2 Data leaning

+,$ data currentl& availa!le 6ith departments are t&picall& prone to multiple data ualit& issues.

7or e/ample@ 8ame4 of a !eneficiar& across various departments< schemes are spelt differentl&

and often does not match the actual !eneficiar& name. The same issues of data ualit& are

more pronounced in address data.

The adoption of Aadhaar ena!led pa&ments and Aadhaar authentication !& various #tate

departments for service deliver& reuires that +,$ data in the departments match those 6ith

DA. The process of updating departmental +,$ data to that of DA +,$ data is termed

5leaning4 in this section.

Data 5leaning is imperative to successful implementation of Aadhaar ena!led service deliver&.

The process of Data 5leaning allo6s a #tate to ensure that +,$ information is correct and

usa!le for various $esident services and #ocial and 7inancial nclusion programs.

*hile cleaning Departmental data using #$D% through APs or 5#: files from #$D% 'atch

#eeding) a Department ma& 6ish to retain preEe/isting Departmental +,$ data in addition to



ᙰ



the #$D% +,$ data. 7or e/ample@ a Departmental data!ase ma& contain t6o fields J for

e/ample one is sa& L8ameM and the other !eing L8ameRAadhaarM.

ver the long term@ one of the intentions of #$D% is to have +,$ data in a standardied andconsistent form across all Departments. ver a period of time@ Departments 6ould move to

rel&ing on #$D% +,$ data e/F L8ameRAadhaaar) 6ithin their data!ases and stop using older

Departmental +,$ data e/F L8ameM). This 6ould ensure consistent and standard +,$ data

across Departmental data!ases.

&.&.& Starting up with clean +,R data

#$D% +,$ data can !e accessed through 6e! services. This can !e leveraged !& an& #tate

application 6here !eneficiaries are appl&ing for a service such as sa& appl&ing for a Ko! 5ard

though an& 8$BA application or through a #tate Portal or through a 5#5 application. n an&

case@ +,$ data for a given Aadhaar num!er can !e fetched from #$D% into the application

form through 6e! services thus ensuring clean +,$ data right at the creation of a !eneficiar&

record in a department< scheme data!ase.

&.&.- Access ontrol

Access to #$D% +,$ data needs to !e controlled to ensure securit& and address privac&

considerations sharing polic&). n that conte/t@ #$D% application usage creates audit records

6ithing the #$D% application data!ase instance. The nodal agenc& should periodicall& revie6

audit trails to ensure appropriate usage of the application. 7urther an& other application

accessing #$D% through 6e! services needs to !e audited to ensure that necessar& audit

details are captured as 6ell as an& data transfer is !oth legitimate and secure encr&pted

transfers).

7urther@ #$D% currentl& onl& allo6s read access through 6e! services. The #$D% application

has an access control module 6hich the application administrator can leverage to provide

individual users 6ith permissions for each separate functionalit& of the #$D% application. t is

important that the #$D% administrator ensures that onl& legitimate approved users can get 6rite

access to #$D% data. 7inall& the #$D% application can !e configured to ensure that an& +,$

data insert or update 6ill first !e authenticated against 5D$ as e/plained previousl& in theData ntegrit&4 section. This configura!ilit& needs to !e setup !& the nodal agenc& thus ensuring

data integrit&.

n order to ensure that Departmental access to +,$ data is secure@ the #tate needs to have in

place the follo6ingF



ᩀ̓


© 2012 All rights reserved. Page 2 of 33

• Departmenta" Data S!aring 8o"icy

There has to !e a Data #haring Polic& defined for #$D% so that onl& the relevant or the

reuired data is shared. This can !e enforced through the access control module of the

#$D% application.

• Data Security

An& transfer of #$D% data to a Department through the usage of *e! #ervices over a

net6or; must onl& happen in a secure encr&pted form.

&.- !perating SRDH at State

perating #$D% at the #tate reuires

• Bovernance structure for o6nership and accounta!ilit& 6ith details of various

sta;eholder roles and responsi!ilities

• %ard6are@ #oft6are and anpo6er reuirements !ased on scale and performance

needs

• anaging #$D% application in terms of

a. ntellectual Propert& $ights P$)

!. 5ustomiation Buidelines including recommended on application environments

and version control

c. ?ocal language support

• Deplo&ment and 5onfiguration guidelines and recommendations

• 5apacit& !uilding in terms of sensitiation@ training and change management

• echanisms to leverage !est practices across #tates and from among departments

6ithin a #tate

• #ecurit& and data sharing guidelines to ensure data integrit& and privac& considerations.

All these a!ove topics are detailed as part of the Lnstitutional 7rame6or; $ecommendations for

#$D% at #tatesM document.



S T


© 2012 All rights reserved. Page 2( of 33

- Appendi

-.1 Functions of SRDH

'unction ame Description

9ogin The login function 6ill !e used to authenticate a user !efore the user

can start using the s&stem. This 6ill also determine the functions 6ithin

the s&stem 6hich the user 6ill !e a!le to access@ !ased on the user

configuration. 8ote that although the #$D% s&stem provides a self

contained user management module@ it can ho6ever !e configured to

use an e/isting ?DAP service 6hich is often availa!le in the #tate

environments 6here the s&stem is e/pected to !e deplo&ed

User 3anagement The user management function is used 6hen the #$D% administrator

or super user 6ishes to add a ne6 user to the s&stem or modif& the

details of an e/isting user or delete a user account. 8ote that although

the #$D% s&stem provides a self contained user management module@

it can ho6ever !e configured to use an e/isting ?DAP service 6hich is

often availa!le in the #tate environments 6here the s&stem is e/pected

to !e deplo&ed.

Insertion o# 0ID

UID #i"e

'atch insert of data into #$D% using one or more encr&pted or

unencr&pted DED file as input. All encr&pted files are e/pected to !e

encr&pted 6ith the #tate registrar pu!lic ;e&. #tate registrar private ;e&

is reuired to decr&pt encr&pted input files to unencr&pted D D H?

files. 7urther processing after decr&ption is the similar for !oth ;inds of

files e/cept that records emanating from unencr&pted DED files can

optionall& !e authenticated against 5D$ !efore insertion< updation into

#$D%. $ecords emanating from encr&pted DED files 6ill not !e

authenticated against 5D$ !efore insertion< updation into #$D%. 7or

records that alread& e/ist in #$D%@ this feature 6ould modif& the data if

the input data is ne6er than e/isting data

Insertion o# a

record manua""y

nsert of a single record into the #$D% using data manuall& entered@

6herein the record is first authenticated 6ith the 5D$ !efore insertion

into the #$D%. 7or records that alread& e/ist in #$D%@ modif& record

functionalit& should !e used



ꗰU


© 2012 All rights reserved. Page 2- of 33


3odi#ication o#

records

odification of a record alread& present in the #$D% using data

manuall& entered@ 6herein the record is first authenticated 6ith the

5D$ !efore modification of the same in #$D% data store.

Resident Se"#

Service o#

insert?modi#y 7:R

manua""y

nsert< modif& of a single record into the #$D% using data manuall&

entered !& a resident through a self service screen of #$D%@ 6herein

the record is first authenticated 6ith the 5D$ !efore insertion<

modification into the #$D%. $esident 6ill need to register 6ith #$D%

and 6ill get an TP temporar& ne Time Pass6ord) !& mo!ile or eail

or !oth and the self service 6ould !e possi!le onl& for a configura!lelimited time period after 6hich resident 6ill have to reuest for TP

again. nce a self service transaction has !een completed successfull&@

resident 6ill not have access to self service unless he reuests for TP

again.

De<activate

records

This function 6ill !e used to ma;e a record inactive. A user 6ith the

deactivate authoriation 6ill search for a particular record or a set of

records The result 6ould !e a standard single record vie6 or a

standard multiple record vie6 matching the search criteria) and then

deactivate them. ach record !eing deactivated 6ill have a LreasonM.

The LreasonM can !e an& one of multiple preEfi/ed reasons as

configured !& administrator 6ith one chosen as default. *hen using

!atch deactivate@ LreasonM is defaulted. This 6ill !e updated in the

#$D% data!ase. ser 6ill !e as;ed to reconfirm the deactivation

Aut!enticate

e-isting records

it! t!e %IDR

This function 6ill !e used to authenticate an e/isting record in the

#$D% 6ith the central 5D$. A user 6ith 5D$ authentication access

6ill search for a record to !e verified The result 6ould !e a standard

single record vie6 or a standard multiple record vie6 matching thesearch criteria). The s&stem 6ill then connect to the central 5D$ to

verif& the record selected !& the user and generate a report that 6ill

sho6 the results of the verification



V


© 2012 All rights reserved. Page 2= of 33


Simp"e searc! This 6ill !e a simple search 6hich 6ill ena!le a user to search #$D%

records. The search can !e !ased on an& of the +,$ data elementssuch as D num!er@ D num!er@ name@ address@ D'@ o!ile

num!er@ email address@ relative name@ relative D<D etc. The D

num!er 6ill !e the default search criteria. The result 6ould !e a record

or a set of records matching the search criteria. #earch 6ill restrict user

to start 6ith a minimum of 3 characters. The result 6ould !e a standard

single record vie6 or a standard multiple record vie6 matching the

search criteria

Advanced searc! This 6ill ena!le a user to search #$D% records !ased on multiple +,$

fields using the A8D logic or to search for records that have !eeninserted<deleted<modified !et6een t6o different dates or a com!ination

of !oth. #earch 6ill restrict user to start 6ith a minimum of 3 characters

for each freeEte/t search criteria. The result 6ould !e a standard single

record vie6 or a standard multiple record vie6 matching the search

criteria.

Seeding uti"ity This functionalit& 6ill allo6 department such as PD#@ 8$BA etc)

users to enter D num!ers and map to their department specific citien

D such as "o! card num!er for 8$BA or $ation 5ard 8um!er for

PD# etc as alread& setup in the Wseeding utilit& configurationW. The

functionalit& can !e operated in single or !atch mode.

n single mode@ user manuall& does the seeding using search to find the

resident record and then mapping to department specific resident D.

n !atch mode@ user uploads a 5#: containing data from the

department pertaining to resident +,$ 6hich is then processed against

+,$ as in #$D%.

n either mode@ the output can then !e do6nloaded as a 5#: file 6hich

6ill have columnsF a) D 8um!er@ !) Department specific 5itien D

and c) ,<8 for record availa!ilit& in #$D% d) +,$ data fields as in

#$D%. This 6ill provide the necessar& preEformatted input to ena!le the

state application data!ases to !e seeded 6ith the Aadhaar num!er.

UIDAI 4au"t <

Up"oad

This functionalit& 6ill allo6 a user to connect to the data vault and

upload files e/pected to !e registrar pac;ets or +,$I data!ase files or

DED H? files) to !e stored for later use. nce a file is uploaded

the metaEdata 6ill !e stored in the #$D% s&stem



ᩀ̓


© 2012 All rights reserved. Page 2> of 33


UIDAI 4au"t <

Don"oad

This functionalit& 6ill also allo6 users to do6nload previousl& stored

files from the vault. *hen the user connects to the data vault@ all the

files that have !een uploaded !& the user 6ill !e visi!le. The user 6ill

place a do6nload reuest to the vault. The vault 6ill respond to the

reuest as per the vault #?A timelines.

Registration o# an

e-terna" database

This is an admin functionalit& to ena!le the #$D% uer& !uilder. This

allo6s the #$D% administrator to register a remote data!ase 6ith the

#$D% s&stem and ma;e it availa!le for the uer& !uilder functionalit&.

8ote that the e/ternal data!ase must alread& have !een seededshould have D num!ers)

SRDH Buery

>ui"der

The #$D% uer& !uilder 6ill !e used to formulate data!ase ueries and

run them against remote departmental data!ases for an& given 4*here4

condition.

Aut!enticate

remote reuests

#$D% 6ill function as an AA and 6ill route all authentication reuests

from registered departmental applications #u!EAAs) to 5D$ and

!ac;. 7or AA server reuirement mainl& #$D% has to implement

Authentication AP. $est of the things are mainl& regarding

infrastructure 6hich states need to ta;e care.

A8I #or reading

SRDH

#$D% 6ill provide an AP interface for ;no6n registered applications to

use for reading #$D% data. All functionalities of #$D% should !e

availa!le through this AP. t is recommended that the #$D% application

itself internall& use the same AP for its !ro6ser !ased . Default

configuration should deplo& #$D% 6ith onl& search and advanced

search functionalities e/posed for other applications to leverage.%o6ever it should !e possi!le to e/pose other functionalities through

configuration. Also@ AP should provide clean and parameteried

interface for all functionalitiesF for e/ample@ 5D$ authentication for

#$D% core functionalities li;e manual record insertion reuires e/act

match authentication !ut the relevant function e/posed !& the AP

should ta;e as input the match settings 6hich the core application

functionalit& uses 6ith e/act match4 parameter inputs



OX




StandardiCed

Reports

#tandardied reports 6ould !e the factual information uantified

results) that a #$D% application portal user 6ould 6ant to see on a

dail& !asis 6hen he<she logs in). 8ecessar& ueries need to !e !uilt for

reporting on 1( metrics



OX



-.2 3odal Agenc% as an A/A

-.2.1 Introduction

AA is an& government < pu!lic < private legal agenc& registered in ndia that see;s to use

Aadhaar authentication for its services. An AA is the principal agenc& that sends

authentication reuests to ena!le its services < !usiness functions.

An AA connects to the 5D$ through an A#A either !& !ecoming A#A on its o6n or

contracting services of an e/isting A#A).

/amples of AAsF

• Department of 5ivil #upplies@ 6hich see;s to verif& the identit& of a target resident !efore

issuing them their monthl& ration of rice@ ;erosene@ etc.

• An& !an; < financial institution that see;s to verif& the identit& of its customer !efore

letting them complete a financial transaction such as 6ithdra6al or transfer of funds.

• The administration<securit& department of a highEsecurit& !uilding<one that see;s to

verif& the identit& of an& individual see;ing entr& into the !uilding<one.

-.2.2 A/A Readiness Stages

• Identi#y business ? service de"ivery needsF The agenc& needs to identif& service

deliver& areas 6here Aadhaar authentication ma& !e used. The agenc& also needs to

decide 6hat authentication t&pes the& 6ould !e using for Aadhaar ena!ling different

service deliver& needs.

• 'i"" on"ine app"ication #ormF An& agenc& interested in !ecoming an AA needs to

appl& online. DA has an online 6or;flo6 !ased application form for engaging 6ith

AAs.

• 0ngage it! ASA(s)F ne of the initial stages for !ecoming an AA is the need to

engage 6ith an e/isting A#A. The list of approved A#As 6ould !e availa!le online and

an interested AA can engage accordingl&. n case an agenc& 6ants to !ecome !oth

A#A and AA@ it 6ould first need to get approved as an A#A and then appl& for

!ecoming AA.

• Send signed contract and supporting documents to UIDAIF The AA should send

hardcop& of the signed contract along 6ith reuired supporting documents to DA. The

online application 6ould !e approved !& DA upon receipt of the reuired documents.

• 0nsure process and tec!no"ogy comp"ianceF The AA needs to setup necessar&

s&stems@ processes@ infrastructure etc. in compliance 6ith DA4s standards and



OX



specifications. #ome such reuirements include defining e/ception handling mechanism@

developing application using Aadhaar authentication APs@ ensuring connectivit& from

authentication devices to the AA server etc. 5ompliance to various reuirements needs

to !e confirmed to DA through the online application form.• 8"an device dep"oymentF The AA needs to decide upon the authentication device

specifications !ased on its !usiness reuirements and ensure deplo&ment of same. f an

AA opts for !iometric authentication@ the sensor<e/tractor of the devices needs to !e

certified !& #TC5. f an AA opts for operatorEassisted devices@ the AA 6ould also

need to ensure training and readiness of operators.

• btain approva"s #rom UIDAIF DA 6ould approve an AA4s application form 6hen

various compliance reuirements are met. An AA should engage 6ith DA during the

process and provide reuired clarifications.

• %arry out end<to<end testingF Approval from DA allo6s an AA to carr& out endEtoE

end testing of their application 6ith the 5D$. 'efore going live 6ith actual residentauthentication@ it is highl& recommended that an AA carries out thorough endEtoEend

testing of their application 6ith the selected A#A and 6ith 5D$. The AA should get the

s&stems related to Aadhaar authentication audited !& information s&stems auditors

certified !& a recognied !od& !efore going live.

• o<"iveF An AA can goElive after confirmation of adherence to all DA4s standards

and specifications. DA plans to manage the same through online 6or;flo6 !ased

application.

-.2.& +e% A/A Responsi"ilities

• 5hoose an appropriate authentication t&pe !ased on !usiness and deplo&ment ris;

assessmentG inform DA regarding the same.

• nsure compliance of authentication related operations processes@ technolog&@ securit&@

etc.) to DA4s standards and specifications.

• Prepare authentication pac;et as per Authentication AP specifications.

• ?og and maintain details of all authentication transactions.

• n case Aadhaar !iometric authentication is used@ ensure 'est 7inger Detection '7D)

application is implemented to onE!oard the residents for !iometric authentication.

• dentif&ing e/ceptionEhandling and !ac;Eup identit& authentication mechanisms.

•

Deplo& fraud monitoring mechanism@ as per AA4s !usiness needs@ to prevent misuse ofe/ception handling mechanism !& operators and an& other ecos&stem mem!ers.

• Bet its operations and s&stems related to Aadhaar Authentication audited as per DA4s

specifications.

• nsure connectivit& from authentication devices to the AA server and !et6een the

AA server and the A#A server.

• Procure@ deplo& and manage devices in compliance 6ith DA specifications.

• nsure adeuate training for the personnel managing authentication devices.



ᩀ̓



• nform DA of the engagement< disengagement of #u! AAs.

• nsure supported #u! AAs compl& 6ith DA4s standards and specifications.

• nform DA of an& misuse of Aadhaar data@ authentication services@ or an&

compromise of Aadhaar related data or s&stems.

-.2.- 0andator% Securit% Re4uirements

• Aadhaar num!er should !e never used as a domain specific identifier.

• n the case of operator assisted devices@ operators should !e authenticated using

mechanisms such as pass6ord@ Aadhaar authentication@ etc.

• PD !loc; captured for Aadhaar authentication should !e encr&pted during capture and

should never !e sent in the clear over a net6or;.

•

The encr&pted PD !loc; should not !e stored unless it is for !uffered authentication fora short period@ currentl& configured as 2 hours.

• 'iometric and TP data captured for the purposes of Aadhaar authentication should not

!e stored on an& permanent storage or data!ase.

• The metaEdata and the responses should !e logged for audit purposes.

• 8et6or; !et6een AA and A#A should !e secure.

ore details on Authentication and AA are availa!le on666.uidai.gov.in<auth.

// 0D ' D%U30 //



OX



uidai - srdh - state adoption strategy

Documents