National Identity Card and Authentication System for the UK

The December 2006 Report, Service Transformation: A better service for citizens and business, a better deal for the taxpayer' by Sir David Varney describes a new coordinated approach for delivering services to individuals and businesses - one where the departments and organizations delivering the service are able to leverage an integrated information system that will improve the service experience for customers and have significant cost savings.

October 7th, 2007

1 Overview

Many of the ideas around Personal Portals and Federated Identity Management play into the approach outlined in this report. Below, I have outlined some high level requirements that can be derived from the Varney Report.

2 Service Customers

2.1 Individual citizens to include taxpaying residents, the elderly and persons in care or custody, minors and other persons who as individuals are recipients of services – this would include aliens and individuals with no fixed address.
2.2 Government departments, businesses, registered charitable or non-profits and other bodies. These organizations are groups of individuals, they have individuals are customers in their own right and they have relationships with each other (in certain cases an organization may be comprised of other organizations)
2.3 The system should be constructed to be extensible where individuals and organizations outside of the UK can be easily incorporated.
2.4 Organizations wishing to become part of this network and thus able to use the authentication service must be registered by an approved appointed body who will perform the necessary checks before allowing them into the network
2.5 Organizations in the network will be assigned certain roles, these will determine how they are able to access, update and control information that they hold about individuals
2.6 The system should provide the ability to allow customers to be uploaded in bulk – into a holding area until they can be verified and fully authenticated (see below).
2.7 The system must be designed to ensure that adding a new organization into the network is straightforward and trustworthy (i.e. to be simple while allowing adequate validation to be made of any new organizations)
2.8 Organizations in the network will have specific roles (e.g. service provider, marketer, data custodian etc. These roles will permit specific actions and relationships.
2.9 Relationships supported will be I2I, I2O, O2I and O2O – which will encompass interpersonal, inter-company and customer and employee relationships between individuals and organizations.
2.10 The rest of this specification will focus on the individual customer and only mention the organizational customer when the needs differ

3 Authentication

3.1 An organization must be able to validate the identity of an individual or other organization
3.2 This functionality must be available 24 x 7, and 365 days per year.
3.3 The response time must be instantaneous at the best case and within specified window where some delay is acceptable
3.4 An organization must be able to authenticate an individual or other organization irrespective of location (i.e. when both the customer and a representative from the organization are physically present together, when only one is present and the other is remote, when both are remote)
3.5 The authentication must be 100% accurate and must generate a system-wide alert should any suspicious or abnormal activity be identified
3.6 The system must work in conjunction with legacy authentication systems already operational within organizations
3.7 In certain instances the system should be able provide authentication services in a disconnected mode, perhaps allowing for a final validation when the system is able to operate in a connected mode once again
3.8 A consistent authentication process should be possible where the same types of unique identification are used and the same standard of checking is made. Different organizations may require further validations in addition to the standard means.
3.9 Authentication would require that a user can be confirmed with a 100% certainty, therefore a means of uniquely identifying the user such as a biometric validation must be used. The biology of the user cannot be forged, but the record of the user's biology must also be encrypted such that without the user, that cannot be altered.
3.10 The system should be extensible such that individuals would be able to authenticate other individuals or organizations
3.11 The authentication service must also be available for a user or organization to authenticate themselves
3.12 The authentication mechanism may be implemented in an evolutionary approach where certain authentication checks for non-critical processes can be made using existing methods, whereas the more critical methods will be authenticated using the most secure means

4 Information Repositories

4.1 The information held about a user (individual or organization) must be accessible by the subject of the information (individual or organization).
4.2 Any organization that maintains information about an individual will be regarded as a custodian of data who will act on behalf of the individual. This is a formal relationship between that individual and the organization and the responsibilities of both parties will be explicitly defined.
4.3 Many organizations hold employee, consumer or customer information as part of the contract between the organization and the individual. When the organization joins 'the network', they gain the ability to authenticate an individual using a source outside of their own systems and potentially the ability to share information with other organizations. Information may be physically or virtually retained by any organization in the network but with the explicit permission of the subject on what information, how it may be shared and with whom.
4.4 The data that is held by any organization must be defined and declared within the network there must be agreed data standards and protocols for storage, update and transfer of such information.
4.5 Data can be the property of the individual, of the data host organization or joint property and the data protocols must include permitted usage cases that pertain to each data type. There must be precisely defined protocols around data ownership and each datum must be explicitly subject to those protocols.
4.6 Certain data that uniquely identifies an individual must be retained by any organization that holds data about that individual (core data).
4.7 Across the network of organizations, the aggregate of the data retained should be able to support the lifecycle of an individual (i.e. birth to death), data that will span the instance of a service and a process (cradle to grave). (E.g. an individual will become a customer of a service, perform many transactions with it and then cease becoming a customer - each step will include data)
4.8 The primary objective is to maintain accurate and consistent data across the organization and to maximize the availability of that information to organizations within the network. This will result in a rationalization of duplicated data across the system, but certain data will be duplicated to ensure system performance
4.9 The system will be designed to allow the existing repositories held by organizations to be leveraged in the data infrastructure - this will entail the core data that identifies an individual being identical across organizations, but each organization will likely maintain its own set of unique information
4.10 Individuals will chose which data they wish to be shared across the network, which data should remain secure with the custodian organization and which data should be made completely public (perhaps under a creative commons license). This must be a standard protocol that it adhered to by each organization in the network
4.11 All data formats must be supported when implemented data standards, ownership and sharing protocols and the transactions that should be performed. Standards would include textual, graphic, photographic, video and other data such as biometric information.
4.12 The aggregated data model held by all organizations within the network and by customers who could also hold their own data locally (as a valid network member) would be extensible to include future data types and associated protocols and ownership protocols
4.13 The system should also recognize existing data protocols and regulations such as HIPAA and OpenID

5 Updating Information

5.1 Core data should be maintained in a consistent state across the entire network of organizations holding data about the individual.
5.2 Changes to that data can be made from any single node in the organization and those changes immediately reflected at all other nodes to maximize convenience, accuracy and to minimize the chances of compromising the data.
5.3 Any change to core data across the network should be authenticated and then made consistently across the entire network. The system must have common processes for authentication and authorization that can be used by all organizations in the network.
5.4 Each organization will additionally be able to maintain data that is peculiar to their own needs, this data will be either the property of the organization or shared with the individual data subject
5.5 A change to core data can be made at any node, online, in-person or remote (that can be carried out by an appointed custodian of that data, say in response to a mailed in form)
5.6 A change to core data should be fully authenticated before it is committed at any host or before it can be propagated across the network
5.7 The risk of fraudulent changes to core data must be minimized or mitigated completely - one possible method would be to issue simultaneous, but inconsistent updates to core identity information at different nodes
5.8 If a change to core data is made erroneously, the facility must be in place to allow that change to be backed-out across the network. Further transactions involving that user should be made instantly and the back-out process made carefully in the time it needs – this may involve reversing other transactions, perhaps including financial commitments

6 Sharing and Profiling Activity

6.1 The existence, volume, type and content of the data should be declared within the network if it is to be shared and should fall under the protocols of permission and sharing
6.2 Organizations will accumulate transactional data for any customer (individual) – this data should be held in a form that will easily facilitate aggregation and analysis
6.3 Analysed information will contribute to a user's profile - this profile should be available for the user to view.
6.4 If the information in the profile is objective (fact based), then the user will have to dispute that information with the organization that constructs it (e.g. customer maintains a negative bank balance at all times)
6.5 If the information in the profile is subjective and the user's opinion or preference will affect that profile, then the user should be able to update that profile (e.g. customer specifies interest in a particular product category)
6.6 The profile information will be created in a standard way that can be accessed by any of the network providers with the explicit permission of the user
6.7 Each organization holding information about a user will want to create a profile that is meaningful to them, hence the method for creating profiles should be extensible such that different organizations can create profiles from different data but the profiles should still be expressed in a consistent way
6.8 The profile information if in a correct format can be used to customize services, to be aggregated to provide market research or to match commercial offers to the user. This type of activity is a potential use of the information and will fall under all of the explicit permission constraints granted by the user to the custodian of the information

7 Information Availability

7.1 Information held by any organization (custodian) should be made available to the organization itself in an appropriate form and to the user in a standard and consistent form across all other organizations.
7.2 Alongside the information, the user should be presented with a means of specifying how that information can be used and shared and with whom
7.3 Should the information be made available for sharing, a precise protocol of how that information transfer will take place including amount of information, level of detail and validity periods - for example information about me from a bank to a merchant stating that I have maintained positive credit in my account will need to specify a period of time which that statement was true, perhaps the level of balance and for how long that information will be valid for the recipient to use
7.4 When one organization makes a request of another for information about an individual, that request must be satisfied within an agreed timescale - protocols must exist for service level between organizations. The system must be able to perform on a zero latency basis should this be the agreed service level
7.5 The system must be constructed in such as manner that information transfers can be specified in a modular fashion - certain types of information being able to be packaged for delivery

8 Service Delivery

8.1 Service delivery functionality must include an audit trail where all transactions, updates, permission changes should be recorded, along with timestamp, source and destinations as a minimum
8.2 The service delivery function will also need a metric on cost to serve or to provide service perhaps measured in monetary, time and resources
8.3 Service delivery can be carried out using the customer's profile - perhaps using profile information to customize the online or offline delivery of the service in real time
8.4 The audit function may also include the ability for the user to provide feedback either actively or passively and that feedback to be passed back to the service provider so they can act upon it, perhaps even in real time depending on the service being delivered
8.5 This functionality will be proactive when the customer is allowed to specify preferences as to how they wish to be treated as a part of their profile information - these will be expressed as a function of the customer services objectives of the organization holding the information

9 Identity Card Management

9.1 Maintaining core data about an individual is a non-trivial task, ensuring that this information is not only accurate but up to date is a key feature of this system. The ability to authenticate a user with 100% certainty is akin to a passport or national identity card. The system will allow an identity card to be provisioned
9.2 The system will not permit a false representation of the user to make updates to core information on the network
9.3 A biometric validation of a user prior to the user making any changes to core information will be demanded.
9.4 Certain organizations that are custodians of an individual’s data will equipped to make that biometric validation
9.5 The biometric validation will be made as part of a public-private key system where the public key is an encrypted version of a biological signature of the user. Hence the private key cannot be replicated as it is the biology of the user
9.6 The user will be able to use normal sign in processes to access and update non-core information at any appropriate node in the network
9.7 When information access is requested, the information will be encrypted with the user’s public key
9.8 When information transfer is requested, the organizations will use their own key pairs to ensure privacy
9.9 The permissions information held by an organization will be encrypted with the user's private key and the organization will have a public key to unlock it and pass it to the requesting organization, prior to the two organization securing the information for the physical journey
9.10 The system will have a series of checks to make sure that the user being created in the system will not be a false entity
9.11 The system must also allow traditional methods of authentication (passwords, passphrases, visual check against official id) to co-exist with biometric methods. Transactions against the most secure parts of the information should require biometric validation and/or encryption, but other less sensitive items can use alternative methods

10 Privacy

10.1 The entire system will be designed around maintaining the privacy of the individual and therefore limited and restricted access to any item of information within it.
10.2 Core data will be maintained in secure locations belonging to network members who have established and contractual relationships with users
10.3 These members may or may not also maintain transactional records
10.4 In addition, these members may or may not derive profile information from the mass of data they own
10.5 With explicit permission a user will be able to allow access to aspects of their profile to other users in the network (users being registered organizations or individuals)
10.6 Core data and transactional records are never shared, which maintains the privacy at all times
10.7 All data that is held and shared should be encrypted with the user's key that will effectively maintain the permission state because only authorized users will have the ability to decrypt the data