Cross Region Delivery Applications

national smartcard project logo

Functional Specification for Oracle CRM Integration WP7-15v6.0

Friday, 7 May 2004

This document describes the technical aspects for integrating the CMS smart card management system with Oracle CRM ; it should be combined with the related functional document (WP7-12) that describes the related processes and data within CRM.

Zip WP7-15 Functional Specification for Oracle CRM Integration v 6.0 (1.61mb)

Retail Payments Sector Considerations WP7-14v3.0

Friday, 7 May 2004

Due to regulation and technology legacy market forces are only able to cost effectively provide certain types of card payment service.

Word WP7-14 - Retail Payments Sector Considerations - v3.0 Release (836.50kb)

Payment service providers, given the massive investment they have made in payment systems infrastructure, are always interested in sources of income and profit.  However market forces, regulation and technology legacy mean that they are only able to cost effectively provide certain types of card payment service. This document has three key objectives:
  • To document the business, operational, regulatory and payment system considerations that will affect the decisions of the retail banks, building societies and other financial institutions when they consider involvement in the provision of payment services to Local Authorities.
  • Highlight any obstacles to their involvement and describe potential means by which these may be overcome.
  • Identify key requirements of any adopted national smart card scheme that would facilitate and encourage retail financial institutional involvement.

Requirements for CRM Interface WP7-12v3.0

Friday, 7 May 2004

This is the National Smart Card Project document that defines an XML schema for a Local Authority Customer Account

Word WP7-12 - Requirements for CRM Interface - V3.0 Release (4.06mb)

This is the National Smart Card Project document that defines an XML schema for a Local Authority Customer Account. It is used as a common view of a customer for exchanging information about the customer and their smart card, between CRM Systems, Smart Card Management Systems (CMS), other Local Authority Systems, and potentially the systems of Central Government agencies and commercial organisations.

It defines the requirements for the interfaces between CRM and a Card Management System, and in particular the National Smart Card Project Starter-Pack Card Management System.

A hub-based messaging system is assumed for integration between all systems, and XML messages are used for exchanging information between the systems.
The system is designed to support the 4 trust levels defined by the Office of the e-Envoy, and, as recommended, uses PKI Digital certificates for secure access to level 2 and level 3 services.

The system is designed to support Smart cards that allow access to services provided by more than one LA, and potentially by other agencies, to support a community of trust across the region, and to allow sharing of components such as the Card Management System between Local Authorities.

Data items held by CRM, CMS and on the card are defined. Where possible the European draft eURI 2003 standard ([5]) is followed for User-Related Information.

The Potential for Federating Identities NERSC WP7-11v2.0

Friday, 7 May 2004

The Potential for Federating Identities:
The NERSC experience

Word WP7-11 The Potential for Federating Identities NERSC v2.0 (4.10mb)

In the Cross Region Delivery Applications section, the National Smart Card Project building on the work of the LGOL Pathfinders, has addressed Authentication as a necessary component for cross-boundary interoperability.

This document aims to provide an introduction to the very complex concept of Federated Identity Management (FiD) with particular regard to the potential that FiD holds for smart card Schemes.  It draws heavily upon the vision for identity management held by the North East Regional Smart Card Consortium (NERSC) and provides a level of detail sufficient to enable the preparation of a detailed specification prior to tender.  NERSC have adopted this approach and have recently embarked on the first stage procurement.  At the time of writing, therefore, the approach is untested.

This document includes an overview of the following:

  • Introduction to the principles of Federated Identity management
  • The overall NERSC requirements for the development of the "Trust Services Network" - the NERSC title for the integration of FiD, PKI and smart card services.
  • An overview of the current or emerging standards that will help to address how these requirements will be met
  • The core technology components required to deliver a solution based on these requirements/standards
  • A recommendation of the products and services required to meet the agreed success criteria

Authentication Overview WP7-09v1.0

Friday, 7 May 2004

This document covers the basic requirement for determining the processes to support the deployment of smartcard schemes.

Word WP7-09 Authentication overview v1.0 release (528.50kb)

This documentation provides an overview of more detailed information held on the National Smart card project extranet.  It has been prepared by Sheffield City Council and covers the basic requirement for determining the processes to support the deployment of smartcard schemes, which will enable citizens to access digital services, where some form of identification, authorisation or signature is required.

The overall objective is both simple yet ambitious.

If these Policies and Processes are adopted by all Local Authorities, then a great step will have been made to allowing interoperability of smartcards across boundaries (ignoring the questions of technical interoperability, which are being addressed elsewhere).

If a smartcard is issued according to the Registration Policy set out here, following the Certificate Policy and its guidelines for implementation in the corresponding Certificate Practices Statement, with Certificate Holders agreeing to the same set of obligations, then it is a solid basis for mutually recognising the smartcards issued by another Local Authority.

All that is then required, is for Authorities to make an Agreement concerning their commitment to adherence to these policies and processes, whilst recognising the consequences of failing to do so. Such an Agreement is also provided on the project extranet.

The Local Authority Smartcard Standards e-Organisation (LASSeO) is referred to throughout the documentation as an example of the kind of organisation needed to be at the heart of these proposals.  This is intended to be descriptive rather than prescriptive. 

With a mechanism established such as LASSeO, to look after these "procedural standards" and to resolve any problems which may incur, progress can then be maintained. Simultaneous effort is being made at a European level to extend this potential for cross-certification across all the EU member states.

Taken together, the documentation sets out the conditions necessary for operating a Public Key Infrastructure (PKI).

The topics covered here and on the project website include:

  • Local Authorities Certificate Policy.
    This is a complete and detailed statement of all the requirements, which need to be met before a digital certificate can be issued.
  • Local Authorities Certificate Practices Statement.
    This states how the Certificate Policy will be practically implemented.
  • Local Authorities Registration Policy
    This sets out the requirements for registering a citizen, organisation or application/device.
  •  Local Authorities Certificate Holder Agreement.
    This is an agreement whereby the citizen acknowledges that they too have responsibilities associated with holding and using a smart card.
  • Local Authorities Application Form for Registration Authority and Local Registration Authority Officials
  • Local Authorities Endorser Agreement.
    This enables help to be gained by utilising "endorsers" in the process of signing up users in certain circumstances.
  •  Local Authorities Certificate Profile.

The documentation represents a stage in the development of local authority thinking and is by no means complete.   The issue of continuing to develop these policies and practices will be considered as part of the overall sustainability of the project outcomes and expert industry input will be welcomed.

E-Purse Cross Regional E-Payments WP7-05v3.0

Friday, 7 May 2004

This report discusses Local Authority issued payment card and their interoperability across national, regional and local boundaries.

Word WP7-05 - E-Purse Cross Regional E-Payments - v3.0 Release (852.50kb)

There is a demand at a closed, local level for the provision of electronic payment methods for a wide variety of Local Authority provided services. The focus for Local Authorities currently centres on the need to improve both quality and access to those services offered within their own Local Authority, where little regard has been given to the needs of providing a common payment scheme capable of being widely accepted by other Local Authorities.

Analysis carried out during the research for this document plus the experience of the authors clearly demonstrates that any Local Authority local or cross border e-payment scheme that represents cash values as opposed to tokens, must allow the cardholder to use that value in payment for a wide range of services and goods. A failure to do so will lead to the "ghetto-isation" of the payment method and ultimately its failure.

The demand for interoperability is a logical consequence of the need to achieve service ubiquity; wide spread acceptance and a consistent basis for transaction processing, clearing and settlement.  This document sets out the basis of this argument.

Finally it is possible to characterise the nature of interoperability and acceptance that is required in order to support the nature of the services for which e-payment is a reasonable proposition.

To enable these services to be paid for by a common e-payment method requires two main areas to be addressed, namely technology and business processes.

Technology that is deployed must conform to standards. Only by conformance will the problems surrounding interoperability and sustainability be overcome. The issues surrounding interoperability and acceptance are covered later within this section.

The other area of greater importance is that of Business Processes. These processes create the rules and govern the way in which the payments operate. They operate above the technology requirements, which tend to focus on the interoperability of components, but operate in conjunction with them to ensure that transactional and exception management conform to legislative procedures and processes.

Existing E-purse Schemes WP7-04v3.0

Friday, 7 May 2004

This document analyses existing E-purse payment schemes.

Word WP7-04 - Existing E-Purse Schemes - v3.0 Released (713.00kb)

In the UK, two major E-Purse schemes have been trialled over the past 10 years, Mondex and Visa Cash. The aim of the schemes was to enter the low value payments market with an alternative to cash in the form of notes and coins. The biggest problem was the cost of running such a system in comparison to the perceived cost of cash as being free.

Mondex is a 'Wallet' or Card-to-Card based scheme that attempts to offer all of the features of cash including person-to-person payment that can be conducted without any intermediary or audit trail. The original Visa Cash product was a 'Stored value' payment scheme where the transactions required 'clearing' through a central system similar to credit and debit cards. Today e-purse activities in the United Kingdom are currently very small-scale. The two pilot schemes, Mondex and Visa Cash, have now both closed. The UK banks have incurred excessive costs in proprietary e-purse schemes with little or no return and can only be described as currently being very averse to hearing the word 'e-purse'.

The UK's biggest problem was intense competition between the major banks and no one body having overall control over the infrastructure to force through any changes. To be successful on a large scale required a 'mass-effect' - millions of cards and nearly total acceptance everywhere, otherwise it would always be seen as 'niche'.
The development and introduction of EMV proved to the major card schemes (MasterCard and Visa) that they could work together to achieve real benefit to the industry they are supposed to be supporting.

The majority of e-purse activity is in central Europe and focussing around the Common Electronic Purse Specification (CEPS), which is administered by CEPSCO. CEPS is a very open specification with the main purpose of ensuring the continued life of the various e-purse schemes in Europe today (GeldKarte, Proton, Visa Cash, etc.) by creating an environment where all these schemes will operate together.

E-purse has been much more successful in Europe because of the centralised approach to retail banking and card schemes in most European countries. This has allowed organisations to develop and implement national schemes without having to gain agreement from various competitive parties resulting in a return on investment through the economies of scale that could be achieved.

The success of a unified specification for the provision of globally interoperable credit and debit payment, in the form of EMV, spurred the drive to create a parallel standard for electronic purse, in the form of CEPS. It is hoped by advocates of e-purse that CEPS will create the same drive for adoption that EMV has created. However it is important to note that EMV arose as a result of the need to standardise what was being implemented on an international basis and CEPS has arisen as a means of increasing the chances of e-purse schemes being deployed. The first, EMV, is a natural role of standardisation after a commercial decision to deploy a technology; the latter, CEPS, may well prove to be an attempt to standardise a solution that is inherently unworkable at a business level.

E-purse Basics WP 7-03 v4.0

Friday, 7 May 2004

This document looks at Smart Card E-purses.

Word WP7-03 E-Purse Position Paper - v 4.0 Release (510.50kb)

Smart card E-purses are able to hold electronic money and can be used to pay for goods or services in particular smart card schemes.  "Accounted" E-purses have transactions recorded by back-office systems whereas "Unaccounted" ones are just like money in that except for audit trails on the card, no transaction records are kept.  Accounted e-purses enable further processing of transaction records, for example, to enable funds to be transferred to different merchants, but because records exist they do pose limited privacy problems.  The back office systems required for accounted systems are also expensive to run.  Unaccounted systems on the other hand have the instant attraction of virtual money but do require expensive security systems to be in place.   

E-purses further divide into "Open" and "Closed" types.  E-purses described as open are ones that can be used for a wide variety of transactions just like money, for example to pay for school meals and library rental and leisure activities etc.  E-purses that are described as closed, on the other hand, are ones with their use restricted to only school meals or only travel etc, and therefore are more like tokens than money.

Value can be loaded into E-purses either by paying cash or by earning points, depending on the scheme.  E-purses can be loaded by bank transfers which can be made to be automatic.  Some schemes provide cash machines which transfer the value of inserted cash onto inserted cards.

The benefits of E-purses are mainly related to convenience and security (not having to carry cash) but schemes need to observe strict regulations.  Large, open schemes operate in a similar manner to banks and are subject to similar stringent regulations.  There are waivers for smaller schemes for which certificates are provided and much less stringent regulations applied.

The legal implication of E-purses is covered in greater detail in WP8-01 Financial Services Act.

Bolton Pilot Specification WP7-01c v2.0

Friday, 7 May 2004

This document defines the infrastructure and software produced and tested to support a Cross-Regional Local Authority Smart Card Scheme.

Word WP7-01c - Bolton Pilot Specification - v2.0 Release (2.47mb)

This section of the National Smart Card Project (NSCP) defines and pilots a Cross-Regional Local Authority Smart Card Scheme.  Such a scheme includes use of the smart card for transport across the region (using ITSO Ticketing), use by applications (such as Library and Leisure Systems) that just utilise the smart card for identification and enrolment, and use by applications (such as School Systems) that require an electronic purse.  The scheme uses the Card Management System produced as part of the NSCP Starter Pack.

This document defines the infrastructure and software produced and tested to support   the pilot, including:

  • The definition of the Card Scheme
  • The appearance, content and capabilities of the cards
  • The infrastructure supplied in the Data Centre, Back Office and Service points
  • Requirements on the use and configuration of the NSCP Starter Pack software
  • Changes required to the enrolment Web site supplied by the NSCP.
  • Details of the software and documentation to be produced
  • Details of the testing to be done
  • Specifications of work required from suppliers: Smart Card Solutions and Cornwall CC
  • Specification of the enrolment process that will be supported for the pilot

One of the outputs of the project is a portable version of the enrolment software that will be used at Service Points.  This consists of the Cardholder database and the enrolment application and Web site installed on a notebook PC, with smart card readers, a scanner and a Webcam attached, and can be used for demonstrations.

Strategic LA Smartcard Architecture WP7-01b v2.0

Friday, 7 May 2004

This document defines the scheme design and architecture for a strategic LA smart card.
Word WP7-01b - Strategic LA Smart Card Architecture - v2.0 Release (737.50kb)

The Cross-Region delivery applications section of the National Smart Card Project (NSCP) encompasses Authentication, CRM Integration and e-Purse Strategy.
This document defines the scheme design and architecture for a strategic LA smart card incorporating all these concepts, and extensions to them.

It describes the benefits that accrue from incorporating all this in a Local Authority Smart card scheme, compared with a simple less strategic scheme, and goes on to explain the on-card and off-card architecture needed to realise it.  It introduces the concepts of:

  • A Citizen's Account with a corresponding e-GIF conformant XML schema
  • Standardised eligibility handling to complement standardised authentication
  •  A generic API for Legacy Integration of authentication and enrolment

The main standards that such a scheme adheres to are: e-GIF Data Standards, eURI, PKI, PKCS#11, PKCS#15, XML, ITSO, EMV, CEPS and ISO 7816.

The document also describes the benefits derived from leveraging the work of several other National Projects.

API for Legacy Integration WP7-01a v2.0

Friday, 7 May 2004

This document supports the usage of the Smart card as an identification and enrolment device

Word WP7-01a - API for Legacy Integration - v2.0 Release (737.00kb)

This section of the National Smart Card Project (NSCP) defines and pilots a Cross-Regional Local Authority smart card scheme.

Such a scheme includes use of the Smart card for transport across the region (using ITSO Ticketing), use by applications (such as Library and Leisure Systems) that just utilise the Smart card for identification and enrolment, and use by applications (such as School Systems) that require an electronic purse.

This document supports the usage of the Smart card as an identification and enrolment device, by defining an API that Application Developers can use for simple Integration with the LA Smart card for these purposes.

The Smart card can also be used to prove eligibility for concessions without the need for producing paper evidence, and the API supports reading the eligibility data and its expiry dates.

The API is designed to support Web-based applications, PC Win32 applications, and client Java applications. After discussions with Bolton and Blackburn suppliers, only the ActiveX version of the API has been productised.  The ActiveX control supports PC Win32 and Web-based applications.  There is no productised version of the Java versions of the API, and hence no native support for Java applications.  However, a demonstration version of the Java applet version of the API has been produced.

Use cases for typical usage of the Smart card by such applications are described, as well as the detail of the API.

WP7-18 esd Risk Analysis Toolkit

Thursday, 22 April 2004

Link to electronic service delivery risk analysis toolkit

WebsiteESD Risk Toolkit

The PID List is a generic list of customer-facing services delivered by UK local authorities. It is controlled and developed by submissions from members of the ESD-toolkit community. Each service included in the PID List comprises of a number of types of interaction between the local authority and its customers. The list of interaction types included in this project is taken from Best Value Performance Indicator (BVPI) 157

WP7-17 Authentication Link

Thursday, 22 April 2004

Link to Authentication website - standardised approach to smart card authentication

WebsiteNational Smart Card Athentication Website

This website has been set up to ensure a standardised approach to authentication is met throughout the country. The site provides details regarding the business process maps developed as a result of this project and gives details concerning each of the four authentication levels, along with descriptions of each level.

Process Maps
Process maps have been designed to make an easy to follow step by step guide to obtaining the required level of authentication.

Authentication Levels 0-3
Each level of authentication requires that a pre-defined authentication process is achieved. All the levels are detailed on this website, along with examples of a typical service requiring this level of authentication.