FRAMEWORK FOR SMART CARD USE IN GOVERNMENT DISCUSSION DRAFT ISSUE 0.4 Central Computer & Telecommunications Agency An Executive Agency of the Cabinet Office Issue No. Date of Issue: Issued By: Reason for Issue: 0.4 1 November 1999 Alan Collier DRAFT for industry and public comment CONTENTS 1 INTRODUCTION 1 1.1 OWNERSHIP AND MAINTENANCE 1 1.2 APPLICATION 1 1.3 WHO SHOULD READ THIS DOCUMENT? 1 1.4 SCOPE AND PURPOSE 1 1.5 SMART CARDS: BENEFITS AND APPLICATIONS 1 2 ACQUISITION ISSUES 3 2.1 CARD VOLUME 3 2.2 CARD ISSUE AND MANAGEMENT 3 2.3 CARDHOLDER ENROLMENT 3 2.4 RISK AND LIABILITY 3 2.5 CONTRACT EXPIRY/TERMINATION 4 3 PRIVACY AND DATA PROTECTION 5 3.1 GENERAL 5 3.2 INFORMATION 5 3.3 SUBJECT ACCESS 5 3.4 SECURITY 5 3.5 CARDHOLDER VERIFICATION 5 4 SECURITY ISSUES 6 5 ACCESSIBILITY ISSUES 7 5.1 STANDARDS ISSUES 7 5.2 OTHER CONSIDERATIONS 7 6 CONTENT AND TECHNICAL STANDARDS 8 6.1 PHYSICAL AND INTERFACE STANDARDS 8 6.2 USER INTERFACE AND TERMINAL EQUIPMENT STANDARDS 8 6.3 PHYSICAL SECURITY 8 6.4 OPERATING SYSTEM STANDARDS 8 6.5 APPLICATION STANDARDS 9 ANNEX A: APPLICABLE STANDARDS 11 A1 PHYSICAL AND INTERFACE STANDARDS 11 A2 USER INTERFACE AND TERMINAL EQUIPMENT STANDARDS 12 A3 APPLICATION STANDARDS 12 1 INTRODUCTION 1.1 Ownership and maintenance This framework is one of a series developed as part of the government's commitment, in the Modernising Government White Paper, to developing a corporate IT strategy for government. It was prepared by the Inter-Departmental Steering Group on Card Technology, which will be responsible for its maintenance. Other relevant frameworks include those relating to authentication and data standards. 1.2 Application This document is endorsed by the Information Age Government Champions. The authoritative text is to be found on the IAGC website at www.iagchampions.gov.uk. Application of this framework by United Kingdom central government departments and agencies is mandatory. The framework has been agreed in consultation with representatives of the devolved administrations of the United Kingdom, of the Northern Ireland Civil Service, and of representatives of the English and Welsh local authorities. It is strongly recommended that all UK public sector bodies apply this framework in order to achieve maximum economies of scale, critical mass and convenience for members of the public and business. 1.3 Who should read this document? This document is aimed at the public sector, broadly defined, and at those delivering services on its behalf. It should be read by: * business and IS managers with a requirement to implement or acquire smart card enabled services; and * technical architects involved in implementing new forms of IT service delivery. 1.4 Scope and purpose Government regards the deployment of multi-function smart cards as a key enabler to the development of electronic commerce and recognises that government applications can act as a key driver towards 'critical mass'. Smart cards may be issued by central government - many existing paper documents may in due course become 'smart' - by other parts of the public sector, and by the private sector. We believe that the ability to use a smart card issued by the private sector, or any part of the public sector, to access the broadest possible range of public services is of benefit to the card issuer, to the card user and to public service providers. This framework is intended to provide a set of standards and guidelines to facilitate interoperability. It is also intended to provide advice on acquisition issues for public authorities; to ensure that accessibility is an integral part of any card scheme; and to provide guidance on data protection issues. Government recognises that smart cards have an important role to play in many government-government and government-business transactions. Much of the guidance in this document is equally relevant to these circumstances. This document should be read in conjunction with the Authentication Framework for Information Age Government, which [will] set out requirements for enrolment of persons into authentication schemes and describe the circumstances in which government will accept particular types of authentication. 1.5 Smart cards: benefits and applications A smart card is essentially a plastic card, the size of a credit card, which bears a small microprocessor. The microprocessor makes the card 'smart' and differentiates it from other plastic cards. A smart card provides the following unique combination of features: * the card can process, rather than just store information; * the card may be programmed, and new applications may be added after * issue; * the card can store comparatively large amounts of information (by comparison with, say, a magnetic stripe card) and can control access to that information. Smart cards have a number of generic benefits and any smart card scheme should seek to gain maximum advantage from these - though not all will apply to every application. * Off-line use. Smart cards act as portable, rewriteable data stores and are therefore particularly suitable for off-line use. This can reduce infrastructure costs and telecommunications charges, and make mobile use practical. However, a careful backup strategy is required to cater for card loss. * Multiple applications. Smart cards may carry multiple applications which may, in principle, be added or removed during the card's lifecycle. This can considerably aid the business case for the introduction of card technology, since a single card can be used for multiple functions by multiple organisations. * Security. Smart card security is not infallible, but smart cards are difficult to counterfeit, compared to most other card technologies, and their processing power and storage capacity provides various security benefits. * Cardholder verification: the card may use a built-in PIN or biometric template to prevent misuse if lost or stolen. The use of biometric identification may also prevent misuse through cards being lent or borrowed: whilst it is possible to acquire a PIN, only the legitimate user possesses a biometric characteristic. * Card and terminal verification: the card and the terminal may mutually authenticate to ensure each is genuine. * Access control and tamper resistance: data intended for different purposes may be stored in discrete parts of the card's memory, and accessed only by authorised persons or applications. * Cryptographic functionality: the card may have sufficient processing power to carry out a digital signature function, without releasing the private signing key to the terminal. This allows the card to be used in an insecure environment, and in multiple terminals, without breaching the integrity of the signature system. Typical smart card applications include: * Electronic purses and stored value cards: these include public telephone cards, public transport tickets, cards for minor items of expenditure in closed environments, and 'open' purse schemes, where the card effectively stores cash value. * Loyalty cards * Identification and access control. Cards may be used to identify either employees or members of the public and to provide access to buildings or computer systems. * Official documents. An increasing proportion of official documents is likely to be issued in the form of smart cards. * Digital signature. Cards may be used - by an individual or an organisation - to digitally sign electronic messages. * Data storage. Cards may be used to hold significant amounts of information, which may be fairly static - such as the holder's name and address or season ticket entitlement - or dynamic, such as a record of attendance at classes. * Mobile telephony: GSM smart cards identify the subscriber to the telephone system and store information such as frequently called numbers. The cards may be moved from phone to phone. * Credit and debit cards - the smart card chip provides greater protection against counterfeiting and may in due course be used to reduce fraud in remote transactions, such as across the Internet, and for cardholder verification. 2 ACQUISITION ISSUES Where a requirement for a smart card has been identified, there are in effect three acquisition options: i) make use of an existing or planned card scheme, without adding an application or data; ii) 'rent space' on an existing card; iii) issue cards oneself, and where possible offset the cost by making space or use available to others. Option (i) may be applicable where an existing card provides all the necessary data and functionality, in an acceptable format, and where technical, commercial and security issues can be agreed. One might, for example, agree to accept a privately issued digital signature card as proof of identity. Whichever option is chosen, the issues set out below should be considered, in addition to the considerations in the other parts of this paper on data protection, security, accessibility and standards. 2.1 Card volume In order to ensure that the highest possible proportion of service users both obtain and subsequently choose to carry the card, it is important to ensure that: * The other applications on the card will benefit and appeal to the intended users and will frequently be used by them; * Any charge levied on users, for the card as a whole, or for individual applications is proportionate to the value which the card offers them. * The other applications on the card will not be perceived as incompatible with the intended application. Users may be unwilling to hold a card if, for example, they fear that sensitive information held on the card for one purpose will be made available when they present the card for another purpose. 2.2 Card issue and management * The card issuer must be willing and able to issue the card to all members of the target user group. If, for example, a card is marketed on the basis of an exclusive image, or is only available to those with a robust credit rating, maybe unsuitable for many public service applications. * There must be a satisfactory understanding regarding card loss and card withdrawal. In what circumstances will a card, or an individual application on the card, be withdrawn? How will public services be provided if a card is lost, withdrawn or stolen? * There must be clear responsibility for managing the customer relationship and for providing 'help desk' services. The card holder must know who to contact in the event of card loss or other contingencies. * There must be a clear strategy for card replacement. In the case of multi-function cards, this may involve re-loading the card with backup data from disparate sources, and it must be possible for the cardholder to achieve this via a single operation. * There must be a clear procedure for card or application withdrawal/cancellation on the holder's death and, where appropriate, in other circumstances such as emigration. 2.3 Cardholder enrolment * All organisations enrolling cardholders must follow appropriate procedures. In particular, if the card itself or an application on the card is to be used to vouch for an individual's identity or status, the issue process must be carefully controlled. This matter is considered further in the authentication framework. 2.4 Risk and liability * Careful allocation and mitigation of risk will be required in any card scheme, and authorities should carry out a formal risk assessment. The potential risks include: * Commercial failure of the scheme. It must be recognised that, where a public service application 'piggy-backs' on a commercial card scheme, failure of the commercial scheme will make cards and infrastructure unavailable to the public sector scheme. This leads to a risk of service unavailability and nugatory investment in software and systems. * Lack of takeup by cardholders- card schemes may completely fail to meet their objectives unless a critical mass of users adopts the card. Careful attention must be paid to the parties' responsibilities for marketing the card, and the contract carefully structured to provide appropriate incentives. * Lack of acceptance by service providers. The usability of the card may depend upon the availability of readers on third party premises. * Technical failure - of the card itself, the infrastructure or in systems integration. * Breach of security. Security must be considered holistically, and includes the technical security of the card, infrastructure and back office systems, the effectiveness of the cardholder verification method in real-world use, and the effectiveness of the audit, accounting and procedural controls applied to the overall scheme. * Unauthorised access to or use of a card or cardholder data, to the cardholder's detriment. Liability to compensate the cardholder, and the limits on the cardholder's liability, must be clearly established. * Damage to a cardholder through reliance being placed on inaccurate or outdated information held on the card. There must be clear procedures for verifying information and for ensuring information is kept up to date, and clear establishment of liabilities and procedures for providing the cardholder with access to the data and with the ability to correct inaccurate entries. * Damage to a third party through misuse of the card by the cardholder. The rights and responsibilities of the cardholder, and liabilities of the parties, must be clearly established. * Inadequate enrolment procedures, where accurate establishment of the user's identity or status or the prevention of duplicate card issue is important. 2.5 Contract expiry/termination Careful consideration must be given to ensuring continuity of service on termination or expiry of the contract, and to ensuring that the authority is in a position to engage an alternative contractor if required. Issues to be considered include: * Ownership of and access to intellectual property, including source code, and of data. * Arrangements for cooperation between the outgoing and incoming service provider. * Agreement of appropriate standards to ensure that applications may be ported to a new platform without undue difficulty. 3 PRIVACY AND DATA PROTECTION Smart cards do not present major new data protection issues, but it is important that data protection issues be considered from the outset. The following is an outline agreement on data protection, to be agreed between the authority and the card/application issuer. 3.1 General The contractor will comply with Annex C (Data Protection and Retention Policy) of Channels for Electronic Service Delivery: Draft Operating Licence, published by the Central IT Unit. 3.2 Information The contractor shall implement procedures to ensure that information held on the smart card, and on any associated data processing or storage system, is accurate, current, and the minimum necessary for the purpose. When no longer required, information shall be purged from the card and associated systems. The contractor shall ensure that information given for one purpose is not used for any other purpose, or passed to any third party, without the subject's informed consent. This means that authorities should only have access to information on the card necessary to carry out transactions with that authority. The contractor shall ensure that the cardholder is informed of: * what information is being held; * the purpose for which it is being held; * when it is being passed on. 3.3 Subject access The contractor shall provide for the cardholder to obtain access to all information held about him on the card and any associated system, in accordance with the requirements laid down in UK data protection legislation at the time of the request. 3.4 Security The contractor shall ensure that the card itself, and the associated systems, are sufficiently secure to protect the information held from unauthorised access, modification or deletion. The contractor shall ensure that information on the card is securely segregated, so that information associated with one application or purpose cannot be accessed by other applications. 3.5 Cardholder verification The contractor shall ensure that the card has an effective method of cardholder verification, and that the cardholder is successfully verified to the card before sensitive information is released or the card used to authenticate the holder for the purpose of any binding transaction. 4 SECURITY ISSUES The implementation of security measures is always a matter of balancing cost and inconvenience against the likelihood of the information held being compromised and the potential maximum impact of any such compromise. It is important to appreciate that card security is not infallible. As cards are easily lost or stolen, it must be assumed that potential attackers will be able to devote considerable time and resources to attempting to break into a card - by destructive or non-destructive means - if they can gain sufficient benefit by so doing. It is hence important to design any card scheme so that the benefit to be gained from obtaining supposedly secret information from a particular card is minimised. Any scheme whereby breaking into a single card can jeopardise the security of the entire scheme is inherently vulnerable and therefore unacceptable. A holistic view must be taken of scheme security, and the schemes designed so that: * the physical security of the card is complemented by appropriate accounting and audit measures; * the likelihood and potential maximum impact of compromise of the information held on the card is minimised; * where possible and appropriate, information is split between the card and the system such that compromising the integrity of either does not breach overall security; * all system components, including terminals, communications links and back-office systems, are appropriately protected. Authorities should consider: * requiring that the card scheme be covered by a security management system independently certified as complying with BS7799; * requiring that the card itself, the operating system and/or the applications be evaluated using the Common Criteria for Information Technology Security (ISO 15408). This is not an exhaustive list of the possible security issues. Authorities should consult the national technical security authority, CESG, if in any doubt. 5 ACCESSIBILITY ISSUES Accessibility is a clear requirement for all public services, and investments in better accessibility can often be cost-effective through increasing the market for a service and by encouraging a greater proportion of the population to use automated systems rather than counter staff. Many accessibility measures impose minimal extra cost, particularly if designed-in from the start. Smart cards themselves, and the devices with which they interface, must be as easy to use as possible. Smart cards may also hold information about the user's particular requirements - for accessibility, type of interface, etc - enabling a better service to be provided. 5.1 Standards issues The following issues are covered by European or international standards, which are listed in Section 6. 5.1.1 Physical design It should be possible to orient contact cards by touch. This can be achieved by placing a notch in one edge of the card, as has been the practice with telephone cards for some years. 5.1.2 Special requirements Special requirements - such as for more time to complete an action, a different interface device, or assistance to access a building - can be encoded on the card and used to assist in providing better service. 5.1.3 Terminal devices Careful design of the terminal itself, of the user interface, and of the transaction process can all make services easier to use without adding significantly to cost. It is also important that the transaction process is carefully designed so that the user is made aware of his/her legal obligations and of any charge involved; is able to cancel the transaction at any point before completion; and can obtain a receipt. 5.2 Other considerations 5.2.1 Card type The type of card used - contact or contactless - should reflect the circumstances. Contactless cards are easier for certain groups to use as they need not be placed in a slot, and are essential for high-throughput ticket gates. However, the low data transfer rate which they provide makes them unsuitable for some applications, particularly where the card is carrying out complex cryptographic functions. Careful design of the terminal and user interaction can make contact cards far easier for all groups to use. 6 CONTENT AND TECHNICAL STANDARDS Whilst allowing the maximum scope for innovation, a minimal set of standards is required to ensure interoperability, avoid 'lock-in' to a particular supplier, maximise accessibility and, where appropriate, ensure security. Organisations procuring smart cards should consider standards at five levels: physical and interface; user interface and terminal equipment; physical security; operating system; and application and content standards. This framework presents preferred standards at some of these levels, and sets out the issues for contracting authorities at other levels. 6.1 Physical and interface standards Physical and interface standards cover the card's dimensions; location and layout of contacts; interface specifications; and so forth. The objective of agreeing standards at this level is to: * ensure that cards may be used in conjunction with any industry-standard reader and that the contents may be read; and * ensure ease of use - by making cards a standard size, and providing an 'orientation notch' to assist visually impaired people. Physical and interface standards are well-defined for contact cards, and for certain types of contactless cards, by ISO standards. Standards for card orientation are defined by CEN. Preferred standards are listed at Annex A. 6.2 User interface and terminal equipment standards It is desirable that users of card-operated devices be presented with a consistent user interface, and that terminal equipment be usable by the widest possible group of users. Guidance on these issues is given at Annex A. 6.3 Physical security The need to set standards for physical security depends upon the application to which the card is being put and the benefit to the attacker of being able to break a single card. As has been noted, smart cards cannot be considered entirely secure against attack and for this reason, card schemes should be carefully designed to ensure that the benefit to be gained from breaking the physical security of a single card does not justify the effort which an attacker would have to employ. For most government-business and government-citizen transactions, authorities are unlikely to wish to specify standards for physical security of the card, and should instead rely on careful scheme design and on careful allocation of risk. Where the physical security of the card is of particular importance, CESG should be consulted, and accreditation of the card's physical security features against common criteria should be considered. 6.4 Operating system standards There are a number of different commercially-available operating systems, each with different strengths and weaknesses. Authorities should consider specifying a particular operating system where application portability (the ability to run the same application across multiple types of cards without rewriting) is an issue, or where there is a requirement for a high level of intrinsic operating-system security. Application portability may be important where multiple partners are contributing applications (such as in an international project), and should also be considered in the context of the strategy for contract termination. Wherever an application is being developed on behalf of an authority, the choice of operating system should be agreed between the parties. The authority should ensure that the chosen operating system is in general commercial use and reasonably 'future proof', to avoid the need for porting of the application to an entirely different platform at contract termination. Again, where operating system security is of particular importance, CESG's advice should be sought and the accreditation of the system against the Common Criteria (ISO 15408) should be considered. 6.5 Application standards Application-level standards are critical for interoperability: they govern the interaction between the card and the terminal. The GSM standard, for example, in essence allows a card running on any operating system to operate with any digital mobile phone. 6.5.1 Government - citizen interaction This section presents a preferred model for cards intended, wholly or in part, to enable citizens to access public services and/or to identify themselves to authorities. The standards identified are applicable in the following circumstances. * Features identified as 'core' should be incorporated in any card issued by or on behalf of an authority, in accordance with the standards specified, unless they are clearly inapplicable to the uses to which the card will be put. * It is recommended that these features are also incorporated in any card issued by a third party which is intended to assist members of the public in interacting with the public sector. Availability of the feature and compliance with the specified standard will maximise the number of authorities willing to accept the card. * Features identified as 'optional' are likely to be of value for public service cards. Where an authority chooses to incorporate any feature given here, it should be implemented in accordance with the specified standard. Similarly, third parties incorporating such features into their cards are advised to implement them in accordance with the standard in order to maximise usability. (a) Application standards - summary of components A public service delivery card may contain some or all of the following components. Component Purpose Status User-controlled profile - 'frequently asked questions' To allow the user to store on the card answers to questions which are frequently asked when dealing with public services - such as name, address and date of birth. Core User-controlled profile - special requirements To allow the user to define any preferences for assisting with special requirements. These may include a preference for, for example, a large typeface; an audible interface; wheelchair access; extra time to pass through a ticket barrier; etc. There is no need to identify the user for these purposes. Concessions profile To store information about the user's status, which may entitle him/her to concessionary fares, reduced price admission, etc. Optional Statistical profile - non-personal data To provide information about the user which is not sufficiently detailed to identify him/her but which is of benefit in identifying public service usage patterns - for example gender, age-group, approximate home address. Core Cardholder verification To identify the legitimate user to the card by means of a biometric template, PIN or other suitable means or combination of means. Core where the card holds sensitive cardholder data, provides a digital signature capability or has significant financial value. Digital certificate (and private signing key) To authenticate the cardholder and allow him/her to digitally sign documents. Optional. Specialist application An application placed on the card by an individual public service which need not interoperate with other public services in general and need not therefore be subject to standardisation. It is the responsibility of individual authorities to consider carefully whether consultation with other authorities is required. As required. 6.5.2 Government-business interaction It is anticipated that a further model, setting out standards for government-business interaction, will be set out. However, none is contained in this draft in the light of work on data type definitions being carried out elsewhere. ANNEX A: APPLICABLE STANDARDS A1 Physical and interface standards All cards should comply with the relevant parts of the following standards: ISO 7810 Identification cards - physical characteristics; ISO 7811-1 Identification cards - recording techniques; ISO 7811-3 1995 Identification cards -- Recording technique -- Part 3: Location of embossed characters on ID-1 cards ISO 7812 - 1:1993 Identification cards -- Identification of issuers -- Part 1: Numbering system ISO 7813 - ISO 7813 Identification cards - financial transaction card; ISO 9992 -1:1990. Financial transaction cards -- Messages between the integrated circuit card and the card accepting device -- Part 1: Concepts and structures ISO 9992-2:1998 Financial transaction cards -- Messages between the integrated circuit card and the card accepting Device -- Part 2: Functions, messages (commands and responses), data elements and structures ISO 10202-1:1991 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 1: Card life cycle ISO 10202-2:1996 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 2: Transaction process ISO 10202-3:1998 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 3: Cryptographic key relationships ISO 10202-4:1996 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 4: Secure application modules ISO 10202-5:1998 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 5: Use of algorithms ISO 10202-6:1994 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 6: Cardholder verification ISO 10202-7:1998 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 7: Key management ISO 10202-8:1998 Financial transaction cards -- Security architecture of financial transaction systems using integrated circuit cards -- Part 8: General principles and overview. In addition, contact cards should comply with the following standards: ISO 9992 -1:1990. Financial transaction cards -- Messages between the integrated circuit card and the card accepting device -- Part 1: Concepts and structures ISO 9992-2:1998 Financial transaction cards -- Messages between the integrated circuit card and the card accepting Device -- Part 2: Functions, messages (commands and responses), data elements and structures ISO 7816-1: Identification Cards-Integrated Circuit(s) with Contacts - Part 1: Physical characteristics; ISO 7816-2: Identification Cards-Integrated Circuit(s) with Contacts - Part 2: Dimensions and location of the Contacts; ISO 7816-3: Identification Cards-Integrated Circuit(s) with Contacts - Part 3: Electronic Signals and Transmission Protocols; and ISO 7816-4: Identification Cards-Integrated Circuit(s) with Contacts - Part 4: Interindustry Commands for Interchange. ISO 7816-5: Identification Cards-Integrated Circuit(s) with Contacts - Part 5: Number System and Registration Procedure for Application Identifiers; BS EN 1332-2:1998 - Identification Card Systems - Man-Machine Interface. Dimensions and location of a tactile identifier for ID-1 cards. Standards for contactless cards are less well defined and no recommendations are made here, other than those given above in respect of all cards. The following is given for information only. The following standards are relevant to close coupling contactless cards. IS 10536-1 IS 10536-2. Proximity cards are defined, to some extent, by the ISO 14443 standard. However, there are a number of well-established cards which do not comply with this standard. Vicinity cards are covered by ISO 15693 A2 User interface and terminal equipment standards It is recognised that there is a heavy existing investment in terminal equipment. It is recommended, however, that new user interfaces and terminals be designed in accordance with EN1332-1- Identification Card Systems - Man-Machine Interface. Part 1 - General Design Principles, and with EN1332-3 - Identification Card Systems - Man-Machine Interface. Part 3 - Design of Keypads It is also recommended that reference be made to Gill, J: Access Prohibited: Information for Designers of Public Access Terminals. London, RNIB, 1998, available at www.eyecue.co.uk/pats A3 Application standards Government - citizen interaction (a) User-controlled profile - 'frequently asked questions' The user-controlled profile allows the user to place information on the card which will assist service providers to deliver service in a more convenient manner. The 'frequently asked questions' part of the profile contains a set of information which is intended to function as a minimum data set applicable to most public service transactions. (b) Content Full name, home address, date of birth and gender of the card holder. Information Standard Full name In accordance with the addition to BS7666 part 3: 1994, proposed by IdeA Home address In accordance with BS7666 part 3: 1994, Spatial data-sets for geographical referencing. Specification for addresses. Date of birth In ddmmyyyy form Gender M or F (c) Ownership The data in this section of the card should be owned by the card holder, who chooses whether to complete it. (d) Access Information held in this part of the user-controlled profile should be accessed only with the user's consent - either through having consented to the release of the information when first signing up for a service, or through entering a PIN number at the time of release. User controlled profile - special requirements (a) Purpose The 'special requirements' part of the card contains information about a user's special requirements for interfaces, access or assistance. It is intended to help public services to provide the best possible service to the disabled and elderly and to meet their obligations under the Disability Discrimination Act, 1995. (b) Content As defined in EN1332-4. (c) Ownership The data in this section of the card should be owned by the card holder, who chooses whether to complete it. (d) Access Information held in this part of the user-controlled profile should be accessed only where the circumstances so dictate - i.e. at a service delivery point equipped to cater for special requirements. Concessions profile (a) Purpose The concessions profile contains information about the user's circumstances (b) Content To be agreed - likely to cover age (if under 18 or over 60) and educational status (whether in full-time or part-time education). (c) Ownership The data in this section of the card should be owned by the issuing authority. (d) Access Information held in this part of the user-controlled profile should be accessed only where the circumstances so dictate - i.e. at a service delivery point offering a concessionary benefit. Cardholder verification (a) Purpose To hold data allowing the card to verify that it is being used by the person to whom it was issued. (b) Content An appropriate cardholder verification mechanism - such as a PIN or biometric template held on the card in one-way encrypted form. (c) Ownership This data must be controlled by the issuing authority. Digital certificate and private signing key (a) Purpose To identify the card holder, and to allow him to authenticate himself and to sign electronic messages. (b) Content The digital certificate should be in accordance with X.509 Version 3. (c) Ownership The certificate will be issued, and digitally signed by, the issuing party or a trusted third party. (d) Access The private signing key should at all times remain on the card, and should not be released to any terminal: hence the card itself must be capable of carrying out a signing operation. No signing operation should be carried out without the cardholder identity being verified by the card, and the cardholder assenting to the signing operation.