Transforming Public Services Conference on eGovernment The Public Services Card Richard Shine

1. Transforming Public Services Conference on eGovernment The Public Services Card Richard Shine Client Identity services Department of Social Protection

2. What Happens Now Individual authenticates his/herself each time he/she attempts to access a public service. Each Public Service Provider authenticates individual prior to assessing eligibility PPSN Issues to Individual Ad-Hoc Verification of PSI/PPSN

3. 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: • time and effort required to authenticate identity • time and effort required to verify personal data • duplication • And that’s when you get it right!!

4. 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

5. Recent Example of Impersonation • Paul Francis Murray • Resident in Thailand since 1974 • Received €249K in fraudulent social welfare payments using 8 assumed identities

6. 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

7. Why? RESULTS Individual • Public Service • Share Data • Share services • Minimise Duplication • Integrate Services • Target Services • Prevent Fraud • Savings Ease of use • Simplify Access • Minimise Repetition (once and done) Maximise Privacy • Control Data Use • Control Accuracy

8. 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

9. Levels Safe 0 = No assurance of identity Safe 1 = Balance of probabilities Safe 2 = Substantial assurance Safe 3 = Beyond reasonable doubt

10. 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

11. 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

12. 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

13. 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)

14. 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 RdB to SQL - facilitate capture of photo, signature, SAFE registration and card lifecycle requests • Procurement for production, personalisation and card management service

15. Sanction received to proceed on 23 October 2009. • MSP Contract negotiations completed. Contract signed on • 22/12/2009 effective from 4 January 2010 • Architecture Design Completed. Development Commenced • Production and Personalisation Facility Design Completed. Construction Commenced • Customer Support Facility Designed and Processes Agreed. Infrastructure development commenced. • Integrated Ticketing Scheme Integration: substantial work completed but integration delayed. • Card Design Finalised • Some Internal Systems Development Completed, procurement for rest commenced • Single Customer View

16. 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.

17. Processes, sub-processes and associated projects Data Capture Card Production Card Management Card Usage Assign SAFE Level (BOMi) Produce PSC (MSP Architecture) Customer Support (MSP Architecture, CIS Ref terminals) Acceptance Infrastructure (BOMi, MSP Architecture, Public Service Providers’ Systems Development) Duplicates Check (BOMi) Application Providers’ Support (MSP Architecture, RPA ITS etc) Request PSC (including renewal) + Response (BOMi, MSP Architecture) Get Voice (Mobile Certification) Get Signature (LOPM, Bulk Load) Card & Terminal Management (MSP Architecture, BOMi, CIS Ref Terminals) Get Photo (LOPM, Bulk Load) Issue PSC (MSP Architecture) Establish Identity ( BOMi, LOPM)

18. PSC Architecture Data Capture (COD, Bulk Load)

19. A Family of Tokens Identity/Access/Payment/Free Travel

20. 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

21. 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

24. Data Inscribed on the Card(Section 263,SWCA 2005 as amended) Name PPS number Photograph Signature Card issue number, and Expiry date

27. 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

28. 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 (?)

29. 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

30. Kinegram Kinegram integrated with the photo and signature

31. By tilting the card the design element will change in colour from gold to green Optical Variable Ink

32. Tactile Relief A positive relief structure applied on the surface of the card

33. 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

34. 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

35. 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

36. 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

37. 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: Advice Use of Public Services Card Use of other card as a Public Services Card Use of infrastructure Use of data