Concepts

The core concepts that underpin the process design for the all-of-government authentication solution are set out below. These concepts are directly derived from the 'authentication principles', and also from the scope prescribed by Cabinet.

Policy and implementation principles for online authentication were approved by Cabinet in April 2002. These principles are published at Online Authentication Principles

ID Credential

An ID credential is a recorded set of identity data, or attributes, provided by a living person and verified by the Authentication Agency using a process to establish identity. The ID credential created by the Authentication Agency is an electronic record containing verified identity data.

The result of a public consultation held in early 2003 was that minimal data would be exchanged between agencies. As such the identity data on the ID credential will be kept to the minimum required to ensure the individual is uniquely identified. The following identity data will be verified and recorded as part of making an ID credential:

• client's names - including the name(s) shown on an official record such as a statutory declaration, previous names, aliases and names created by administrative error;
• client's gender; and
• client's date and place of birth.

Administrative data about the ID credential (credential attributes) such as the date when the ID credential will expire, and an audit trail of the data received and verified during the process of creating the ID credential, will also be recorded as part of the ID credential.

Principles associated with ID credentials:

• there will only be one type of ID credential;
• a Client can have only one individual ID credential;
• only the Authentication Agency will issue and verify ID credentials; and

an ID credential can only be issued to and used by the person to whom it belongs.

A person cannot use another person's ID credential on 'behalf' of them, for example on behalf of minors. Guardians and attorneys may use their own ID credential to identify themselves, but cannot use the ID credential of the person they are acting on the behalf of.

Key

In an online environment, a Client must be able to demonstrate that they are authorised to access/present an ID credential. This is typically achieved by possession of a Key , which authenticates the Client. A Key is the technology that allows the Client to unlock and provide the information on their ID credential to a Service Agency.

Examples of types of Keys include: Client name/passwords, card/PIN, one-time pass codes and digital certificates.

Principles associated with Keys:

• Keys must be unique;
• a Client can have one or more Keys. (Most Clients will only want and need one Key. A Client could choose to have multiple Keys);
• different types of Keys could be used in the all-of-government authentication solution;
• a Key has no value until it is authorised to access something;
• Keys can be issued by entities other than the Authentication Agency; and
• Service Agencies will not hold copies of their Client's Keys.

Use of Key & ID Credential

Cabinet directed that privacy protection be one of the fundamental design assumptions for the authentication solution. There was also a clear direction that national ID cards or anything similar NOT be considered as part of the design solution. These two directives from Cabinet were a strong influence on the design and led to the separation of the Key and ID credential functionality.

Separating the Key and ID credential:

• prohibits the Key being perceived as an identity card, because the Key does not impart identity data and does not expose the ID credential data at every transaction without the Client authorising the release;
• provides the Client with a choice as to which Key they use and when;
• means the Client can reuse the Key for pseudonymous transactions, in addition to authenticated transactions;
• will allow a Client to choose to have many different Keys, while avoiding the unnecessary duplication of the ID credential;
• allows the Client to revoke a Key if they are concerned about security or privacy protection, without the cancellation of the ID credential; and
• provides greater flexibility for agencies delivering services (e.g. they can retain their own existing Key technologies and processes).

Pseudonymous transactions do not require identity to be established, only that repeat visits by the same pseudonym be recognised. For a pseudonymous transaction the Service Agency needs to check the Client's Key but not the Client's ID credential.

Evidence of Identity (EOI)

Evidence of identity [EOI] is the process by which an agency establishes, to a high degree of confidence, a person's identity. This means the person provides sufficient evidence of their unique identity and also evidence that they own the identity they are claiming.

It is important to have sufficient Evidence of Identity to ensure to a high level of certainty that service information (e.g. personal health information) is going to the right person, because inappropriate disclosure might impact on personal privacy or safety.

Evidence of Identity must be established before an ID credential can be issued.

The following diagram shows the components that together constitute acceptable Evidence of Identity for the all-of-government authentication solution. It is important to note that if one of the components is missing the agency may still know enough about a person to be able to interact with them to a certain level, but this does not mean that they have comprehensively established Evidence of Identity.

In the case of ID credentials, which would be a trusted identity data source, evidence of identity must always have been established - i.e. all of the components must be satisfied in order for an ID credential to be issued.

All of the components of the Evidence Of Identity Framework must be satisfied to establish the identity of an individual to a high level of certainty. Refer to the 'Implementation Details' section for further information on EOI.

Figure 1. EOI Components. (extracted from the 'Evidence of Identity Framework' bythe Cross Agency Evidence of Identity Project on 10 September 2003)

Request Verified Information (RVI)

Cabinet directed that privacy protection be one of fundamental design assumptions for the all-of-government authentication solution. To provide privacy protection, when a Service Agency requires personal information to be verified, it must first ask the Client to release their ID credential. The Service Agency does this by providing the Client with a Request Verified Information (RVI) number. The Client presents this number to the Authentication Agency and authorises the release of their ID Credential data to the Service Agency.

For further information, refer to the description of the 'First Time Service Registration' process in the next section of the document.

The RVI number will contain information about:

• which Service Agency has made the request to release the ID credential information;
• the Key serial number of the Client making the request; and
• date and time details of when the RVI was generated.

Agency Authentication

From the Client's point of view, a critical part of authentication is checking that they are presenting their Key and providing information to a genuine Service Agency.

Incidences of 'fake' official websites are a growing Internet security issue. As a potential example; a Client receives a fraudulent e-mail that appears to be from a government agency. The e-mail contains a link that redirects the Client to a replica of the agency's official website, which has been set up in order to extract the Client's username and password.

Therefore, as part of the all-of-government authentication solution, Service Agencies must be able to authenticate themselves to Clients, so people are confident they are dealing with a real government agency.

Agency authentication is commonly achieved through a combination of technology and consistent style.

Technology - Most Internet users are familiar with websites that display a padlock, indicating a secure connection between the website and the user's browser. This padlock can be used as a check of the authenticity of the government website's domain name.

Style - Most people know how government agencies look and behave via the traditional delivery channels such as post or phone. For example, people know that government correspondence looks a certain way and if they get a letter on plain paper they think 'that's a bit strange'. Government agencies will have to start describing what indicators people can expect to be present in dealing with them, e.g. always providing the person's customer number (a shared secret) at the beginning of the process.

Refer to the 'Implementation Details' section in this document for more information.

Actors

For formal definitions of the actors refer to the Glossary section.

The parties that play a role in the all-of-government authentication solution are:

Authentication Agency - the government agency responsible for establishing the identity of the Client and with the Client's approval, authenticating the Client to Service Agencies.

Client - an individual seeking to interact with another party and carry out a transaction.

Key Provider - an agency or agent's authorised to issue accredited Keys to a Client.

Service Agency - a government agency or agent responsible for delivering a service to Client.

Shop-front - a local office or agent of the Authentication Agency that when necessary enables the Client to interact 'in person' with the Authentication Agency.

Trusted Referees - the parties trusted by both the Client and the Authentication Agency to vouch for the Client's identity.

Review Body - an independent agency that Clients can ask to intervene when they believe they have been incorrectly treated or adversely affected by a decision made by an agency as part of the authentication process. Note: The Review Body is not typically part of the daily operation of the authentication system.

The diagram below shows the relationship between the actors and provides an overall context of the proposed authentication solution.

View a larger version of this diagram

[ Previous | Next ]