3. Description of the Project & Information Flows

3.1. The project and information flows can be described in a number of different ways. The most useful initial means is as a series of linear, chronological steps in an online transaction to conduct business with the Government.

3.2. The simplest description is that a service user goes to a government website, say the Ministry of Social Development (the Service Agency) to conduct some business, such as filing a required document, applying for a benefit or the like. The Service Agency will have business rules governing how an individual must confirm their identity before being allowed to use online services. This might involve some offline process, such as presenting evidence of identity at an office of the agency, or answering a series of questions on the telephone, or an online process, carried out in the initial session. Once the Service agency is satisfied that the person is who they say they are, i.e. identity has been established to an appropriate confidence level, the Service User will obtain a key from the key provider. The key will have a serial number. The GLS will assign a unique random number for the key that is specific to that Service Agency that will be transmitted to the Service Agency when the key is presented. The number will be the same each time the key is presented. When the Service Agency receives that number from the GLS, they will link it to the identity originally established and permit the Service user to conduct their transaction, according to the Service Agency's own business rules that apply for a key of the strength that has been presented.

3.3. Some important features of the process are as follows:

3.4. Identity establishment is not a feature

3.4.1. The Government Logon System is not involved in identity management, establishment or registration. It is for the Service Agencies to establish the level of verification of identity that will be required for certain transactions, and to implement sufficient procedures to ensure against identify theft and fraud in ways which minimize the impact on privacy.

3.4.2. While it may seem somewhat artificial to decouple establishment/ management of identity from the issuing and use of keys, to do so best suits the objectives of the project. The GLS can in no way be seen as a "Trojan horse" for a more comprehensive and privacy intrusive process of managing online access to government services.

3.4.3. It is self evident that there will be a demand from service agencies for an efficient centralised system of establishment of identity, and separate work is ongoing on the establishment of some form of "authentication agency". The natural home of such an agency is within the Department of Internal Affairs, but final policy decisions are yet to be confirmed on these matters.

3.4.4. It is clear from a consideration of the GLS project, and of the earlier work by Pacific Privacy Partners that it is in relation to establishment of identity issues that the majority of the most serious privacy issues arise. The project intends to commission and undertake further work on the privacy impacts of the establishment of identity component of online authentication for government workstream in the coming months.

3.4.5. One of the key features of GLS is that service users can use as many different keys as they choose to, including multiple keys with the same Service Agency. For example, the GLS will not know that the same service user has multiple different "identities" for the purpose of the GLS. The GLS will also not know whether a user with multiple separate keys are separate users or just one unless the Service User chooses to group them together for convenience. This gives a significant level of privacy protection. Whether that level of protection will be undermined by the establishment of identity options remains for consideration as part of the privacy impact assessment of that project. The GLS component is clearly sufficiently flexible to give effect to users choices as to the level of privacy protection they wish to achieve.

3.5. Key Strength and role assignment is managed by the Service agency

3.5.1. The GLS is a "passive" conduit for passing information about the validity of a key to the service agency.

3.5.2. Different service agencies will have different rules about the strength of key required to access different services. Further, each Service Agency will also have its own rules as to what a person is authorised to do, the role that the person is playing, the service entitlements, and the ways in which users can access services. For example, some service agencies may allow access to certain services with a low identity risk to a person with a weak key. An example might be the use of a username and simple password to file certain documents with the Companies Office.

3.5.3. These issues do not affect the way in which the GLS confirms identity for the Service Agency.

3.6. The second way to describe the project and information flows is to assume each actor is a separate agency, and to set out the information needs of each. Some items are personal information and some are not. For the purposes of this analysis, the functions associated with key provision, and with the common logon service are described separately, even though institutionally, the functions will be carried out in the same organisation, the GLS. These functions may be split in the future, or further key providers added, either of which will trigger further privacy impact analysis.

3.7. A useful table provided by the project team demonstrates the distribution of access to different items of information among the principal functions:

3.8. This table shows that no actor other than the Service User can link the key with identity and clearly demonstrates the separation of roles.

3.9. It is not however, a comprehensive list of personal information held, and for the purposes of the privacy analysis, an attempt at such a list is set out below. For the purposes of this list, the different functions of the CLS and KP are described separately, even though it is intended (at least initially) that those functions will be carried out by the same agency, the GLS.

3.9.1. Service Agency

• All the Service User's personal information generated by, or given to that Agency
• Transaction logs (e.g. date and time of access), together with details of services used on that occasion
• A session ID, a different unique identifier created for each attempt by a Service User to access a resource that requires authentication. This number matches the Service User trying to access a secure online service with the returned authentication assertion (that is, a message about the key validity and strength) from the GLS.
• A second session ID, a different unique identifier created during each session. This number remains constant throughout the session so that the Service Agency can perform its own business processes, e.g. access control, session timeout, removing the need to re-authenticate with the GLS for online services with the same or lower key strength, etc.
• Modified Key Serial Number, the number from which the Key Serial Number has been converted. It is unique to the Key and to the Service Agency and also communicates the fact that it has been validated.
• Key strength used by the Service User to authenticate at the GLS

3.9.2. GLS (Common Login Service)

• A Session Id that is used to track the Service User's request for authentication in a single session
• Transaction logs recording the date and times a particular key has been presented, outcome (successful, failed, etc.), etc
• Modified Key Serial Number
• Key Serial Number
• Root Key Serial Number which is the key(s) or KSN(s) that the Service User has chosen to group together to generate the same MKSN (in other words, where a service user chooses to use the same key(s) to access several Service Agencies, a new MKSN will be generated for each agency but is linked with the group of keys rather than each single key. The CLS must retain a record of the MKSNs that are derived from a given RKSN and KSN)

3.9.3. GLS (Key Provider)

• Challenge and response information for providing user assistance (i.e. a secret question and its answer provided by the user initially which the user can use to confirm themselves for online self service or offline customer support).
• User contact information (email address) for the Service User to be emailed their reset password. Other forms of contact information may be added in the future, depending on the nature of the keys offered. For example, a physical address may be required to dispatch tokens, or a mobile phone number to send text messages.
• Potentially, other personal information for billing purposes, where necessary, optional credit card details, postal address etc.

3.10. The parameters for the system design have been set by Cabinet decisions. The summary (taken from the RFP) of the policy decisions taken for the Authentication project as a whole provide a helpful insight into the policy drivers affecting the technical solutions selected:

Key Policy Principles

The Government has agreed the following key policy principles for electronic authentication of individuals carrying out transactions with government agencies.

• Security - Suitable protection must be provided for information owned by both people and the Crown
• Acceptability - Ensuring that the proposed authentication approach is generally acceptable to potential users, taking into account the different needs of people and emerging industry standards, and avoids creating barriers
• Protection of privacy - Ensuring that the proposed authentication approach protects privacy appropriately
• All of government approach - Balancing public and agencies' concerns about independence with the benefits of standardisation while delivering a cost-effective solution.
• Fit for purpose - Avoiding over-engineering, recognising that the levels of authentication required for many Government to People transactions will be relatively low.
• Opt-in - Ensuring that members of the public retain the option of authenticating their identity and carrying out transactions offline and are not disadvantaged by doing so. However, it will not be possible for an individual to conduct secure online Government to People transactions without the use of the appropriate authentication process.

3.11. In addition, there are Implementation Principles that have been endorsed by Cabinet which forms the basis of the implementation of the conceptual design:

• User Focus- Ensuring the recommended solutions are as convenient, easy to use and non-intrusive as possible
• Enduring solution- Providing a solution that is enduring yet sufficiently flexible to accommodate change and a wide range of current and future transactions
• Affordability and reliability- Ensuring the recommended solutions are affordable and reliable for the public and government agencies
• Technology neutrality- Ensuring a range of technology options is considered, and as far as possible avoiding 'vendor capture'
• Risk-based approach- The solution must comply with relevant law, including privacy and human rights law
• Legal certainty- Relationships between the parties should be governed in a way that provides legal certainty
• Non-repudiation- The issue of non-repudiation must be considered for those transactions that require it, so that the risk of transacting parties later denying having participated in a transaction is minimised
• Functional equivalence- Authentication requirements should be similar to those that apply to existing transactions except where the online nature of the transaction significantly changes the level of risk