Trust Services Infrastructure – enabling multi-brand multi application smartcards SCNF Northern Showcase Event 26 th October 2004 Euan Tennant Technical Programme Manager, NERSC

E-government Architecture Secure Presented in the way I prefer Seamless integration cross boundary Giving me Tailored joined-up service I want This is how it looked to us in ?

Hardware and Operating System Layer Middleware Persistent data layer Master Index Shared Workflow and Message Hub Portal Integration layer Local interaction Channels Local interaction PortalIndexHub Hub to Hub interactions Application layer Domain of Integration Other Domains We are not alone: There are other domains around us.

Hardware and Operating System Layer Middleware Persistent data layer Master Index Shared Workflow and Message Hub Portal Integration layer Local interaction Channels Local interaction Portal Index Hub Application layer Universal point of access: the catalogue of catalogues Federated Identity Management Service Universal point of publication, recourse and resolution. Domain of Integration Other Domains Federation Services Smart Cards: Integrating the integration technologies Accepting networks Identity tokens and keys Brand Apps Pocketable data

NERSC Public Sector Interests Commercial Interests App. owners Brand owner Accepting Networks Issuing Network PE Card Manufacturers Transaction & settlement Bank Clearing & settlement User Support Services (hub) Master registers Trusted Services Provider Registration & Authentication Cards Commission a set of trusted core value chain support services Facilitate collective procurements on behalf the brand and application owners

Card Scheme Components CARD MANAGEMENT SERVICE PROVIDERS PKI APPLICATION PROVIDERS CARDS FEDERATED IDENTITY MANAGEMENT HELPDESK

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

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 Authentication in the multi-app world

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

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 3 rd 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’ Making multi-app smartcards work Pre-requisites (continued)

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