Electronic Waivers — Technical Considerations

April 09, 2011

Ryan Matteson
Security Consulting
Office of Chief Information Officer
Cal Poly San Luis Obispo

The question arises again and again — ‘Can we administer a waiver of liability with the computer? Motivations range from reduction of paper work to ease of administration. While case law is available related to the use of waivers in paper format, there have been few if any published legal ‘tests’ of electronic waivers.

Especially critical to the implementation of an electronic waiver are the issues of authentication and affirmation of the user, and this article describes the key process that need to be considered.

Signature
Specific requirements for signature are defined by existing law, and any solution must be vetted by legal counsel. Given this, from a strictly technical perspective, there are two main aspects: authentication and affirmation. Authentication establishes that a uniquely identified individual is present. This can be provided by e.g. login using a username and password. Affirmation establishes that the authenticated user took a specific action requiring intent e.g. selecting a checkbox to acknowledge a statement.

Authentication of Users
Many organizations already have a standardized authentication process, which allows a single username and password to be used across many different services. Some organizations will have a web single sign-on solution, such as the Central Authentication Service developed by JA-SIG, which allows the user to access a variety of services based upon a single entry of their username and password.
Regardless of the specific technology used, most authentication will involve the following elements:

1. A unique identifier, such as a username, for each person who is authorized to access services. This username may be related back to other information for the user, such as full name, age, or other information stored in a database.
2. A password associated with each username. To be of benefit, this password must be known only to the user. This is often accomplished in part by enforcing “password strength” rules which reduce the possibility that a password may be guessed. For example: Passwords may not contain dictionary words.
   The password is further protected using technical measures such as hashing, encryption, access control rules, timeouts and ticket-based protocols with the result that the organization can have confidence that only the intended individual is able to authenticate to their username. Optionally, additional measures such as certificates or time-based passwords may be used to establish higher confidence in the authentication of the user; the expense and complexity of these measures must be balanced against the risks for a specific organization.
3. An audit trail which records usage of the username and password and, separately, password change/reset activity. In both cases timestamps and location (such as network IP address) are included in the trail. This type of system could be implemented to authenticate users to a campus web portal and associated applications such as e-mail, calendar, PeopleSoft HR and Finance. Based on our specific passwords rules and monitoring practices, this authentication approach has been found acceptable through many independent audits.

Affirmation
Given an authenticated user (above) a web-based application may prompt the user to respond to questions and store the results so that they may be reviewed and acted on by another user. In the case of a web-based waiver of liability, an application would:
1. Present to each user a statement, a checkbox to acknowledge agreement with the statement, and a button to record the checkbox setting. This may be implemented so that the action is permanent and the user is not provided a mechanism to “undo” the change.
2. An audit trail, searchable by username and other fields using common database access tools, showing actions taken by users (e.g. “jsmith@university.edu checked the acceptance box on Jan 30, 2007 at 09:00”). For each user it is simple to establish whether or not the box has been checked. This information may then used within processes or systems to limit or allow activity. For example, a user may be allowed through a turnstile at a recreation center only if they present an identifying card and have checked the checkbox to waive liability. This information is kept for a specified number of years following the end of the user’s relationship with the organization. The technology is able to store this information indefinitely given adequate planning for storage requirements, and so retention period should be driven by business or legal requirements.
3. This functionality to waive liability is accessible at any time via the web. Separate communication to users may be accomplished via posters, face to face interaction, or other method to introduce the process.

Items Requiring Special Consideration
The first step in designing a system of this type is to clearly understand all legal requirements, and existing technology which may be used to support implementation.
Without sufficient advance planning there may be substantial effort in managing multiple waivers (waiver per event or setting) and a large number of people/processes which must be aware of and act on waivers. The following requirements should be understood and documented:

1. Collection of data describing each event: the population of users that must have the waiver, the location of each event, contact information if different from that already on file, any applicable deadlines for completion of a waiver, and the individuals or office who must be notified when the waiver is or is not completed.
2. Some mechanism for sending notifications to those who must complete waivers and those who must verify completion. Email is one option.
3. Support staff/process for addressing issues or questions raised by users.
4. Reporting if applicable (e.g. oversight and summarization by a risk management office).
5. Integration with any existing or planned automated processes. For example, making waiver information available to the systems which operate turnstiles.
6. Rules for restricting access to information (which information may be viewed or updated and by whom).
7. Integration of paper-based process when necessary: who is responsible, how is data entered, is electronic system the “master” authoritative record or is this split across paper and electronic.

If these items are all adequately addressed, web based systems may provide a very efficient and user-friendly approach for establishing waiver of liability.