Transforming Public Services Conference on eGovernment

The Public Services Card

Richard Shine

Client Identity services

Department of Social Protection

Individual authenticates his/herself each time he/she attempts to access a public service.

Each Public Service Provider authenticates individual prior to assessing eligibility

What Happens Now

PPSN Issues to Individual

Ad-Hoc Verification of PSI/PPSN

• 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 identityo time and effort required to verify personal datao duplication

And that’s when you get it right!!

ISSUES

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

Paul Francis Murray

Resident in Thailand since 1974

Received €249K in fraudulent social welfare payments using 8 assumed identities

Recent Example of Impersonation

PSI AuthorityPublic Service Identity Data RegisterSingle Customer ViewSAFE Manager

Client Registers Personal Data

Token (e.g. PSC) issues to Client

What Should happen

Why?Why?

Maximise Privacy

Ease of use

Public Service

• Share Data

• Share services

• Minimise Duplication

• Integrate Services

• Target Services

• Prevent Fraud

• Savings

•Simplify Access

•Minimise Repetition (once and done)

•Control Data Use •Control Accuracy

Individual

RESULTS

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 processToken – photo & PIN, thin clientInfrastructure – existing, where possibleApplications – mainly AuthenticationDSFA to issue PSCFurther work on policy - CMODFurther work on registration & card functional specification

Safe 0 = No assurance of identity

Safe 1 = Balance of probabilities

Safe 2 = Substantial assurance

Safe 3 = Beyond reasonable doubt

Levels

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

· Authentication by observation: The PSC shall have physicalcharacteristics that give a trained inspector a level of assurance that theyare 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 (‘non-chip’ requirements)

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 RdB to SQL - facilitate capture of photo, signature, SAFE registration and card lifecycle requests

Procurement for production, personalisation and card management service

o MSP Contract negotiations completed. Contract signed on 22/12/2009 effective from 4 January 2010 o Architecture Design Completed. Development Commencedo Production and Personalisation Facility Design Completed. Construction Commencedo Customer Support Facility Designed and Processes Agreed. Infrastructure development commenced. oIntegrated Ticketing Scheme Integration: substantial work completed but integration delayed.oCard Design Finalised o Some Internal Systems Development Completed, procurement for rest commencedoSingle Customer View

Sanction received to proceed on 23 October 2009.

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.

More To Do

Data Capture Card Production Card Management Card Usage

Duplicates Check(BOMi)

Get Signature(LOPM, Bulk Load)

Get Photo(LOPM, Bulk Load)

Establish Identity( BOMi, LOPM)

Produce PSC(MSP Architecture)

Customer Support(MSP Architecture, CIS Ref

terminals) Acceptance Infrastructure(BOMi, MSP

Architecture, Public Service Providers’

Systems Development)

Processes, sub-processes and associated projects

Get Voice (Mobile Certification)

Assign SAFE Level(BOMi)

Request PSC (including renewal) +

Response(BOMi, MSP

Architecture)

Issue PSC(MSP Architecture)

Card & Terminal Management

(MSP Architecture, BOMi, CIS Ref Terminals)

Application Providers’ Support

(MSP Architecture, RPA ITS etc)

PSC Architecture

Data Capture(COD, Bulk Load)

Copyright ©Accourt Limited 2003

Agency SystemApplication 3

Agency SystemApplication 2

Adrian Cannon5678912345

0 12 16 66 AGE

Lifetime Identifier

PublicService Card 1

ID/ACCESS/PAYMENT

DrivingLicence

Special Health Card Passport

Delivering Identity and Authentication Services

PPS Number

Adrian Cannon5678912345

IDENTITYPHYSICAL ACCESS

Agency SystemApplication 1

Private SectorApplication A

Public Service Card 2

Health SystemApplication 1

HigherOrderCards

Higher order cards must deliver lower level functions.

Identity/Access/Payment/Free Travel

A Family of Tokens

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

• By tilting the card the design element will change in colour from gold to green

Optical Variable Ink

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

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.AdviceB.Use of Public Services CardC.Use of other card as a Public Services CardD.Use of infrastructureE.Use of data

What We Can Do For You