Key Authentication Issues

When is Authentication Needed - Managing Risk

Authentication is generally needed to manage the risks or prevent the adverse consequences that can arise when a transaction fails in some way. These risks or consequences may be borne by the government agency, the individual, both parties or, in rare cases, a third party. Risks exist in G2P transactions when:

• private information is involved;

• financial value is involved;

• the transaction verifies the individual's entitlement to something; and

• the transaction effects a change in legal status.

There are some exceptions. Transactions such as paying taxes are unlikely to attract impersonators, so authentication may not be a major issue. Other transactions may involve notifications to existing persons or addresses, or payments to known bank accounts, so that there is a lesser need for authentication.

The types of risk that may arise for individuals and Government include:

• inconvenience to the identity holder;

• risk to the identity holder's personal safety or property;

• release of personal or commercially sensitive data to third parties;

• the risk of financial loss to any party;

• risk to a party's standing or reputation, including loss of public confidence in core government systems or services; and

• effects on the commission or detection of serious crime.

(This categorisation is based on the UK Government's "Trust Level" framework, used to determine levels of authentication.)

Making Authentication Work - What do Users Need?

A number of user-focused questions need to be considered in developing an authentication framework. These include:

• how capable will the user group be of using the required technology?;

• will the user group access the authentication system from the same computer/ application (eg many users of one PC in a household)?;

• how much will the authentication technology cost the user (including any need to upgrade personally owned technology, on both a one-off and on-going basis)? Can they afford this?;

• what are the compliance costs regarding time and effort?;

• do users perceive the authentication process as having sufficient security and managing their risks effectively?; and

• how does this group view the relative importance of risk and convenience?

Question:

What are the key usability limits that will need to be taken into consideration for G2P transactions (e.g. technology levels, complexity of process ?

Weighing up Risks and Convenience / Cost

At the current stage of development, authentication technologies which offer most protection also tend to be more expensive, complicated to learn, and are often inflexible.

New Zealand experience to date indicates that users tend to favour the most convenient methods of authentication. The question of the relationship between user preferences and who bears the cost in the case of an authentication failure is important. Some systems users may be acting as agents for those who will ultimately suffer loss from a failure in authentication and, therefore, could excessively favour convenience over security. Other users have been willing to bear considerable risk in order to avoid the inconvenience of a "strong" (PKI-based) authentication system.

The issues associated with tradeoffs between convenience and risk will often be different for government agencies than for commercial entities. Banks for instance, routinely transfer the risks of misuse of card/PIN systems to customers or vendors. Such risk transfer will not be possible or appropriate for the Government in situations where customers have a legal entitlement (say to a benefit) under statutory regulation.

Question:

Are there types of transactions or risks where the potential risks involved mean that risk should always be considered ahead of convenience; or transactions where the needs of users mean that convenience should always be put before risk considerations?

The Registration Role

All authentication processes rely on an initial process that is frequently called registration. This is the process by which the individual's identity (or evidence of identity (EOI)) is established and registered with the agency, the result of which will be relied on to confirm that identity when authentication takes place. Some kinds of transaction may contain elements of registration, e.g. the processing of passport applications, which involves careful checking of identity.

PKI-based (Public Key Infrastructure) authentication processes rely on organisations known as Certification Authorities to collect and verify the EOI information. Some governments carry out the Certification Authority functions themselves or have oversight of the accreditation of commercial providers. Australia, for instance, has set up a system for accrediting certification authorities against stated criteria.

Question:

What is the appropriate role and level of involvement for the New Zealand government in registration processes underpinning authentication?

An Alternative System - Holding Individuals' Identity Data

The Irish Government has provided for an electronic 'dossier' of information about individuals' identity, which can be held on their behalf by an independent agency. Individuals will be able to update their information and control the access to it by government agencies. This system has the potential to save individuals the task of repeatedly providing the same information, and could provide agencies with a level of assurance about the quality of the information they receive.

Although such a system offers potential benefits to authentication, and lowers compliance costs, it is wholly dependent on public acceptance and uptake. It is also predicated on an existing system that has already assigned a unique identifying number to each potential user. The ease with which such a model could be applied in New Zealand is unknown. It is certainly clear that New Zealand privacy legislation explicitly bars the type of unique identifier used by the Irish government.

Question:

Do we want to adopt an authentication framework such as that in Ireland that requires changes to existing privacy legislation to allow for unique identifiers? (This approach could be included as an opt-in element in a broader framework that did not use a universal unique identifier for G2P transactions).

A Graduated Approach to Authentication

The level of risk involved in each type of G2P online transaction will vary. If a graduated approach to authentication is adopted, the type of authentication used can be matched to the level of risk the transaction entails. Where the risk is considered high, a "strong" authentication process is likely to be recommended. Where the risk is lower, a "weaker" form of authentication would be considered acceptable and appropriate. This approach would depend on acceptance of an agreed framework for identifying levels of risk. Frameworks of this type are already in use by the USA and UK governments.

Questions:

Do we want to adopt a graduated approach to authentication built on an agreed framework for identifying levels of risk?; and

What should the framework consist of?

A Single "Strong" Authentication Approach

One alternative would be to apply a "strong" authentication approach to all G2P transactions. This approach has already been adopted in certain countries; examples are Singapore and a number of European countries such as Finland. The common factor in all cases is that these countries have a long-standing acceptance of the use of a unique identifier that individuals use in their dealings with Government. It is also generally accepted, even expected, that a substantial amount of personal information will be automatically divulged to the Government and publicly available. In contrast, New Zealand has a long-standing aversion to the use of a unique identifier in dealings with Government, and New Zealanders tend to set a very high value on personal privacy.

Question:

Do we want to adopt a single "strong" authentication approach built around the use of a unique identifier that individuals use in their dealings with government?

Central Provision for Authentication

It would be possible to provide for individuals to authenticate themselves (possibly to different levels) at a central location, say on the Government portal. They would then be able to transact (at the level to which they had authenticated themselves with different agencies). Such a system would be desirable only if individuals needed to transact with several agencies and valued a consistent and central means of authentication. It could be compared with having a "master key".

The disadvantages of centralised authentication include the possible perception that other things (such as information sharing) may be occurring behind the authentication process. Centralised authentication (even if levels of authentication were involved) would also reduce the ability of government agencies to match authentication techniques to their judgements about the risks involved in transactions, and the demands of the statutory regimes under which they occur.

Question:

Do we want to adopt a central system of authentication where individuals authenticate themselves (possibly to different levels) at a central location - say, the Government portal?

[ Previous | Next ]