Transforming Public Services Conference on e. Government The Public Services Card Richard Shine Client Identity services Department of Social Protection
What Happens Now PPSN Issues to Individual authenticates his/herself each time he/she attempts to access a public service. Each Public Service Provider authenticates individual prior to assessing eligibility Ad-Hoc Verification of PSI/PPSN
ISSUES • Multiple unlinked silos of data • Ad hoc data verification/matching • Inconsistent/inaccurate data • Duplication for individual supplying same data to many Public Service Providers • Resource implications for Public Service: o time and effort required to authenticate identity o time and effort required to verify personal data o duplication And that’s when you get it right!!
Do you recognise this Man ? Ø Eastern European Ø Obtained 10 PPS numbers in 2005 using stolen Lithuanian Passports Ø Aged between 25 and 31 when photo taken
Recent Example of Impersonation Ø Paul Francis Murray Ø Resident in Thailand since 1974 Ø Received € 249 K in fraudulent social welfare payments using 8 assumed identities
What Should happen Client Registers Personal Data PSI Authority Public Service Identity Data Register Single Customer View SAFE Manager Token (e. g. PSC) issues to Client
RESULTS Why? Individual Ease of use • Simplify Access • Minimise Repetition (once and done) Maximise Privacy • Control Data Use • Control Accuracy Public Service • Share Data • Share services • Minimise Duplication • Integrate Services • Target Services • Prevent Fraud • Savings
Standard Authentication Framework Environment Rules based standards for establishing and authenticating identity to facilitate access to public service across multiple channels. In July 2005 the Government approved the SAFE Business Requirements: Registration – unified registration process Token – photo & PIN, thin client Infrastructure – existing, where possible Applications – mainly Authentication DSFA to issue PSC Further work on policy - CMOD Further work on registration & card functional specification
Levels Safe 0 = No assurance of identity Safe 1 = Balance of probabilities Safe 2 = Substantial assurance Safe 3 = Beyond reasonable doubt
Level 2 • Minimum authentication level for PSC and most public services • Face to face registration in a designated SAFE Registration Office • Capture of photo and signature • Proof of identity and evidence of address
Functional Specification – Public Services Card Principles • Privacy enhancing: Personal data shall only be used when necessary, and the PSC shall be implemented in such a way as to enhance, not weaken, the protection of that personal data. • Future Flexibility – A family of tokens – Thin Client (functionality in backend systems) – Multi-channel support
Functional Spec (‘non-chip’ requirements) · Authentication by observation: The PSC shall have physical characteristics that give a trained inspector a level of assurance that they are looking at a genuine card. · Cardholder photo on card face: The PSC shall have a cardholder photo on the front of the card · Expiry date: The PSC chip shall hold an expiry date, configurable by the card issuer to a value appropriate to card usage · Free travel: The PSC shall be usable for gaining access to legitimate free travel. This might simply mean using the card as a flash pass or might be electronic authentication
Functional Spec (‘chip’ requirements) • • • • Secure online authentication Secure offline authentication Level of confidence in authenticated identity Support for cardholder PIN SAFE cardholder data Cardholder facial image stored on the chip Card data access control Card chip block, unblock and termination Identifying card capabilities Confidentiality Integrity Trial of biometric authentication (S) Trial of contactless technology (S)
A Lot Done ü ü ü ü ü SAFE Programme (incl Government Decision) Legislation Assessment of PSI Data Procurement of Technical Advice and Support Registration Process Review (incl Fraud & Error Survey, Rationalisation of PPSN Registration Centres) PSC Functional Specification Organisational Review (incl future state vision and process mapping) Customer Object Development (COD 1): Transfer of Customer records from Rd. B to SQL - facilitate capture of photo, signature, SAFE registration and card lifecycle requests Procurement for production, personalisation and card management service
Sanction received to proceed on 23 October 2009. o MSP Contract negotiations completed. Contract signed on 22/12/2009 effective from 4 January 2010 o Architecture Design Completed. Development Commenced o Production and Personalisation Facility Design Completed. Construction Commenced o Customer Support Facility Designed and Processes Agreed. Infrastructure development commenced. o. Integrated Ticketing Scheme Integration: substantial work completed but integration delayed. o. Card Design Finalised o Some Internal Systems Development Completed, procurement for rest commenced o. Single Customer View
More To Do § Complete development of new functionality § Complete specification, build and test of architecture § Complete Assessment of DSP registration capacity § Devise strategy for enrolment of residual population § Implement Robust Registration Process (incl. provision of hardware e. g. digital cameras, scanners, signature pads, passport readers etc) § Phased Roll Out (incl. acceptance infrastructure e. g. card readers) Continue to work towards early integration with ITS.
Processes, sub-processes and associated projects Data Capture Assign SAFE Level (BOMi) Duplicates Check (BOMi) Get Voice (Mobile Certification) Get Signature (LOPM, Bulk Load) Card Production Produce PSC (MSP Architecture) Request PSC (including renewal) + Response (BOMi, MSP Architecture) Card Management Customer Support (MSP Architecture, CIS Ref terminals) Application Providers’ Support (MSP Architecture, RPA ITS etc) Get Photo (LOPM, Bulk Load) Card & Terminal Management (MSP Architecture, BOMi, CIS Ref Terminals) Establish Identity ( BOMi, LOPM) Issue PSC (MSP Architecture) Card Usage Acceptance Infrastructure (BOMi, MSP Architecture, Public Service Providers’ Systems Development)
PSC Architecture Data Capture (COD, Bulk Load)
A Family of Tokens Identity/Access/Payment/Free Travel
Design Requirements • Standard “credit card” size with multiple protection mechanisms to prevent and detect tampering with the physical card and its contents • Immediately recognisable as being for use in the public services of Ireland • The card must comply with the best practice on accessibility and also the Official Languages Act
Design Requirements • The design must ensure that the combination of the photograph and the name are sufficiently prominent • The design is to incorporate over-printable areas where the “Free Travel entitlement” or similar variable data can be printed
Data Inscribed on the Card (Section 263, SWCA 2005 as amended) • • • Name PPS number Photograph Signature Card issue number, and Expiry date
Data Encoded on the Card (Section 263, SWCA 2005 as amended) Name PPS number Photograph Signature Card issue number • Expiry date • • • Date of birth Sex All former surnames (if any) of mother Place of birth All former surnames (if any) Nationality
Multiple Security Features • Polycarbonate Card • Laser Engraving • First Line Security Features (3) § Easily and speedily recognisable • Second Line Security Features (2) § Require specialist equipment • Third Line Security Features (? )
Polycarbonate Card • Polycarbonate card body with laser engraving personalisation • Five layers of material inextricably bound by heat lamination so they cannot be split without destroying the card • Coloured background print - intrinsic security feature
Kinegram • Kinegram integrated with the photo and signature
Optical Variable Ink • By tilting the card the design element will change in colour from gold to green
Tactile Relief • A positive relief structure applied on the surface of the card
Second Line Security Features • Design includes second line security features • Their detection will require specialist equipment • For obvious security reasons features will not be made publically available
Third Line Security Features • Design includes a number of third line security features • For security reasons exact details of third line security features will only be disclosed to 2 nominated individuals in CIS • Examples of third line security features would include intentional ink spots and slightly tilted characters
Accessibility Features • The tactile relief is a raised structure which allows visually impaired people to detect the orientation of the card • The contact chip of the PSC is also tactile. This element clearly defines the orientation of the card and aids visually impaired people to use the card correctly
Immediate Benefits • Validation of Identity – provided SAFE principles are not undermined • Potential for substantial reduction in the rate of fraud and error • More secure payment token – chip and pin • Data enrichment – SAFE 2 registration • Replacement of current insecure cards • Efficiencies across the Public Service
What We Can Do For You PSC can be used by any Public Service Provider that is entitled to use the PPSN (S 263, 2005 Consolidation Act) Co-operation focus areas: A. B. C. D. E. Advice Use of Public Services Card Use of other card as a Public Services Card Use of infrastructure Use of data
Скачать презентацию Transforming Public Services Conference on e Government The
864c5a5abee0f422b5dd9b6f0aa966d8.ppt