Transforming Public Services Conference on
eGovernment
The Public Services Card
Richard Shine
Client Identity services
Department of Social Protection
What Happens Now
PPSN
Issues to
Individual
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 €249K 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 RdB 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.
oIntegrated Ticketing Scheme Integration: substantial work
completed but integration delayed.
oCard Design Finalised
o Some Internal Systems Development Completed, procurement
for rest commenced
oSingle 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
Delivering Identity
and Authentication Services
Higher order cards
must deliver lower
level functions.
Higher
Order
Cards
Special
Health Card
Passport
ID/ACCESS/PAYMENT
Identity/Access/Payment/Free
Travel
Health System
Application 1
Public
Service
Card 2
Agency System
Application 2
Adrian Cannon
5678912345
Agency System
Application 3
IDENTITY
PHYSICAL ACCESS
Public
Service
Card 1
Lifetime
Identifier
Driving
Licence
Private Sector
Application A
Adrian Cannon
5678912345
Agency System
Application 1
PPS Number
0
Copyright © Accourt Limited 2003
12
16
66
AGE
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