1 Design factors

1. During research about the security issues related to online authentication, a number of design factors were noted. This document lists these factors, for consideration during the design of any online authentication system.
2. These factors should be reviewed alongside the Cabinet Paper Authentication Principles approved by Cabinet on 22 April 2002.

1.1 Insult rate

3. The authentication process must not be time consuming or difficult for the user to experience. This factor is known as the "insult rate".
4. Studies have shown that if the insult rate is too high, the user will go somewhere else or will use a different channel to complete the transaction. Authentication can be made to appear seamless, thereby meeting the insult rate objective.

1.2 Privacy

5. For authentication to work, it is essential that the authenticating agency have access to the appropriate types of identifying data necessary to implement an authentication process. This means that the agency must have the right, and the means, to obtain the identifying data needed to independently verify the individual.
6. There is, of course, a corresponding obligation on the part of the authenticating agency to recognize their responsibility concerning the use of this data. They must responsibly maintain the data and use it in accordance with the purpose for which it was provided.

1.3 Solution requirements

1.3.1 Flexibility

7. Any proposed solution should be flexible in how it could be used to prove identity. If a solution only provides proof of identity when the credential is used on the Internet, this could severely limit its usefulness as organisations move to provide their services over a variety of future channels such as cell phones, messaging services and digital TV.

1.3.2 Simplicity

8. Any proposed solution must be simple and not in addition to applying for other forms of Government credentials.
9. Any proposed solution must be usable by as many people as possible. This includes the very young, the very old, people with disabilities and people from many cultures.

1.3.3 Reusable

10. Any proposed solution must be usable by more than just government to maximise benefit e.g. business, individuals, etc.

1.3.4 Cost of implementation

11. Any proposed solution must be cost-effective for the users. Compliance costs must be minimised for the users, http://www.dpmc.govt.nz/cabinet/circulars/co01/2.html.

1.3.5 Robustness

12. Any proposed solution must be able to recover from compromise with minimal disruption.

1.3.6 Social impact

13. Any proposed solution must have minimal social impact. It must include all parts of the community for example by

• Accepting and handling cultural sensitivities
• Accepting and handling physical disabilities

1.3.7 Justice

14. Any proposed solution must allow for breaches. It must minimise suspicion, embarrassment and arrest. It must provide ways to prove one's innocence. Users must understand that the system can be wrong.
15. System design needs to carefully consider the following:

• the repudiability of an assertion. This includes such questions as how an (id)entity contests information stored on another (id)entity's records;
• the onus of proof. This involves establishing on which (id)entity the responsibility lies to establish that data is or is not of appropriate quality; and
• the allocation of costs. This determines which party bears the cost and inconvenience that arises where the quality of data is contested.