Transcript Document

Trust Services Infrastructure
– enabling multi-brand multi
application smartcards
SCNF Northern Showcase Event
26th October 2004
Euan Tennant
Technical Programme Manager, NERSC
E-government Architecture
This is how it
looked to
us in 2000
Presented in the way I prefer
?
Giving me Tailored
joined-up service
2004
Seamless integration
cross boundary
I want
Secure
Other
Domains
Domain of Integration
Channels
Integration layer
Portal
Portal
Master Index
Shared Workflow
and Message Hub
Local
interaction
Index
Hub
Local
interaction
Application layer
Persistent data layer
Middleware
Hardware and Operating System Layer
We are not alone:
There are other
domains around us.
Domain of Integration
Accepting
networks
Channels
Integration layer
Identity tokens
and keys
Portal
Shared Workflow
and Message Hub
Portal
Federated Identity
Management Service
Hub
Universal point of
publication, recourse
and resolution.
Local
interaction
Brand Apps
Application layer
Persistent data layer
Federation
Services
Universal point of
access: the catalogue
of catalogues
Index
Master Index
Local
interaction
Other
Domains
Pocketable data
Middleware
Hardware and Operating System Layer
Smart Cards:
Integrating the
integration
technologies
Public Sector Interests
Commercial Interests
NERSC
Commission a set of
trusted core value
chain support services
Registration &
Authentication
Clearing &
settlement
Cards
Trusted
Services
Provider
User Support
Services (hub)
Master registers
Facilitate collective
procurements on
behalf the brand and
application owners
Transaction
& settlement
Bank
Brand owner
App. owners
Accepting
Networks
P
E
Issuing Network
Card
Manufacturers
Card Scheme Components
CARD MANAGEMENT
FEDERATED
IDENTITY
MANAGEMENT
PKI
CARDS
SERVICE PROVIDERS
HELPDESK
APPLICATION
PROVIDERS
Card Scheme Success Factors
• Useful
– There is little point expecting people to cherish their
smartcard if it can only be used to access services which
are not part of their daily lifestyle routine
• Useable
– If its too slow the user may be too impatient to complete
a transaction (rip and tear)
– Avoid proprietary cards which may limit the range of
acceptance networks available for the user
– If using digital certificates – its got to be simple!
• Used
– Once you are live be prepared to support users as a bad
experience can be a big turn-off
Card Scheme Killers
•
•
•
•
•
•
•
•
Participants fall out (legal action ensues)
No ‘killer’ (compelling) applications
Applications stagnate
Applications redundant
Too expensive (business case does not exist)
Scheme not scaleable (architectural constraint)
Incorrectly targeted marketing (think channels!)
Too many bugs leads to loss of confidence
National Project Risk Register – deals with legal risk – don’t
forget operational and financial risks as well!
Authentication in the multi-app world
• A token will be used to assert an
authenticated identity or role - potentially
in many different environments with
differing liabilities appertaining
– Be wary of conferring identity risks particularly
at low levels of authentication
– Don’t assume that low level means free read for
all card data
Authentication in the multi-app world
• What level of authentication can a smartcard
support? Biometrics/PKI/SKI etc
– Only by using a digital cert can you ensure non-repudiation
of a transaction – that the message was not tampered
with and that the principals private key was used and was
valid – necessary to achieve level 3
• Aren’t Digital Certificates expensive?
– Largely depends how pervasive the PKI has to be
– Recommend that the LA ‘Citizen’ is PKI only used to
authenticate to the Citizen’s Account . Leverage this with
SAML authentication assertions to partner web-services
Making multi-app smartcards work
Pre-requisites
• Understand that 80% of scheme cost
happens after the card is issued (it may
last several years).
– You will need to think about strategies for
extending the card’s earning potential e.g. guest
apps
– Be prepared for significant churn
(cancellations/failures/lost and stolen)
– What about card durability (PVC 2-3yrs)
Making multi-app smartcards work
Pre-requisites (continued)
• On-card data has to co-exist but a guest service
provider has to believe that their data will be
secure and not disclosed to or changed by others.
– Often schemes fail because service providers do not
trust the card issuer to do this (no rental income)
– Solution: Use proxy identity information (as in Liberty)
thus guaranteeing SP customer data is not compromised
– Benefits to operator: increase in Trust and can allow the
operation of 3rd party application load services (even for
other card management systems)
Making multi-app smartcards work
Pre-requisites (continued)
• Ensure Inventory Control from the start
– it may be fine to run a small pilot on a manual system but
tens of thousands of cards issued will quickly generate
real challenges for version control and card re-issue
• Card management systems must be able to manager
applications lifecycle after the card has been
issued
– What happens when the application rules / policies
change?
– How does the user add ‘guest applications’
Post Issuance Issues
• Why do it?
– more cost effective (than re-issuance), more functionality
(less wallet space), doesn’t depend on everything being in
place at issuance (allows management of time constraints)
phased roll-out.
•
•
•
•
•
•
But
Security
Version control
Ease of management
New applications
Business Rule changes (applications)
Application termination
Convergence Issues
(Retail, Banks, Mobile Operators and Transport)
• The benefits --- useable, useful & used
• The issues:
– Big Industries……. single council….working in partnership
….may not be easy to achieve
– Branding
– Legal e.g data protection
– Governance – what role for the individual citizen?
– Working with standards e.g. ITSO, EMV, Tscheme
• Certification & accreditation
• Commercial frameworks
Thank you!
Euan Tennant
[email protected]