6

Authentication, Privacy, and the
Roles of Government

Government institutions play multiple roles in the area where authentication technologies intersect with privacy concerns. Not only do all levels of government (state, federal, and local) use authentication systems, but the technologies are employed within and across government institutions at each level as well. Furthermore, government plays multiple roles in the authentication process. As a relying party, government uses authentication technologies for electronic government applications and for physical and systems security applications. Given the size of its workforce and its user base, government is a significant user of these technologies. The government’s role in the authentication process (as regulator, issuer, and relying party) is important, since so many forms of authentication or identification rely on some form of government-issued identity or identifier.

It is not surprising, therefore, that government organizations have conflicting and supporting roles in authentication. As an example, the Social Security Administration (SSA) fills all three roles simultaneously. The Social Security number (SSN) was designed by SSA for its own use in recording earnings. For its intended purpose, in conjunction with other SSA business processes and controls, the SSN’s security level meets the SSA’s requirements. In this case, the SSA is both the issuing and the relying party, so the incentives for risk mitigation are properly aligned.

When the parties that issue and rely on an identifier are different, the incentives for risk mitigation are not necessarily aligned. For instance, secondary uses of the SSN have proliferated, beginning with their use by the Internal Revenue Service (IRS) and state taxation agencies, and now extending to many private sector organizations such as credit reporting agencies. There is an inherent conflict between the higher confidence levels desired by the relying party and the extra cost imposed on the issuer to meet this confidence level. For example, it is probably neither reasonable nor cost-effective for the SSA to change its SSN issuance and maintenance processes in order to help the private sector manage business risk around creditworthiness just because most credit bureaus use SSNs as unique identifiers for credit history. An examination of the various roles that government fills in authentication processes and privacy protection, anchored by specific examples, helps to explain this complexity.

The issuance of IDs illustrates how different levels of government interact with the public through specific programs for sometimes unique reasons. The principle of federalism—the division (and in some cases overlap) of government responsibilities among federal, state, and local government,¹ designed into the U.S. constitutional form of government—helps to explain why it is important not to view the government role in any area as monolithic.

By design, as protected by public law and policy, government activities are assumed to be fair, impartial, and immune from commercial manipulation.² This legal and policy context for the government management of information and related technology makes government use of these technologies a special case and certainly different from their use by the private sector. Individuals who are citizens of or permanent residents in the United States also have a unique relationship with government agencies. Sometimes by choice, and in many instances by compulsion, citizens and residents are both participants in governance and users of government goods and services. For instance, citizens may choose to comment on proposed changes in information-reporting requirements such as the questions on census forms. Alternatively, some relationships with government are straightforward and contractual, just as with a business. For example, when it is time to repay student loans, beneficiaries have a legal obligation to return the money that they borrowed from the government with interest.

Unlike private sector organizations, though, public agencies cannot choose their customers. Public law and regulation instead of business plans dictate whether an individual is a beneficiary or a regulated entity. While private sector organizations may only want an individual’s business under certain conditions (for example, one can only get a mortgage or a credit card upon meeting certain eligibility criteria), most citizens interact with government organizations from cradle to grave. From the recording of birth to the issuance of death certificates—and annually in between for some government programs—citizens’ interaction with government is virtually inescapable.

Finding 6.1: Many agencies at different levels of government have multiple, and sometimes conflicting, roles in electronic authentication. They can be regulators of private sector behavior, issuers of identity documents or identifiers, and also relying parties for service delivery.

REGULATOR OF PRIVATE SECTOR AND PUBLIC AGENCY BEHAVIORS AND PROCESSES

The government acts as a regulator of multiple sectors, including health and medical services, financial services, and education. For this analysis, these regulatory activities are put in three groups: (1) government-wide law and policy that are focused internally on the activities of federal agencies in a particular domain (for example, privacy, electronic government, or computer security); (2) program- or agency-specific law and policy that apply to specific types of transactions but may cut across a number of government agency and private sector organization boundaries for transactions such as federally funded health care or higher education; and (3) public law or policy intended to regulate the information management activities of the private sector broadly or more specifically in certain areas such as financial services. This section summarizes some of this public law and government policy and concludes by identifying some pending legislation that is relevant to privacy and authentication.

Government-wide Law and Policy

Privacy Act and Computer Matching Act

A recent Government Accounting Office (GAO) report³ refers to the Privacy Act of 1974 (5 U.S.C. Sec. 552a)⁴ as the “primary [U.S.] law regulating the federal government’s collection and maintenance of personal information.” Generally speaking, the Privacy Act aimed at balancing the federal government’s need to maintain information about individuals with the rights of individuals to be protected against unwanted invasions of their privacy. The act attempts to regulate the collection, maintenance, use, and dissemination of personal information by federal government agencies. As one source summarizes, the act provides privacy protection in three ways:

1. It sustains some traditional major privacy principles. For example, an agency shall maintain no record describing how any individual exercises rights guaranteed by the First Amendment unless expressly authorized by statute or by the individual about whom the record is maintained or unless pertinent to and within the scope of an authorized law enforcement activity.

2. It provides an individual who is a citizen of the United States, or an alien lawfully admitted for permanent residence, with access and emendation arrangements for records maintained on him or her by most, but not all, federal agencies. General exemptions in this regard are provided for systems of records maintained by the Central Intelligence Agency and federal criminal law enforcement agencies.

3. The act embodies a number of principles of fair information practice. For example, it sets certain conditions concerning the disclosure of personally identifiable information; prescribes requirements for the accounting of certain disclosures of such information; requires agencies to “collect information to the greatest extent practicable directly from the subject individual when the information may result in adverse determinations about an individual’s rights, benefits, and privileges under Federal programs”; requires agencies to specify their authority and purposes for collecting personally identifiable information from an individual; requires agencies to “maintain all records which are used by the agency in making any determination about any individual with such accuracy, relevance, timeliness, and completeness as is reasonably necessary to assure fairness to the individual in the determination”; and provides civil and criminal enforcement arrangements.⁵

However, passed in great haste during the final week of the 93rd Congress, the “Act’s imprecise language, limited legislative history, and somewhat outdated regulatory guidelines have rendered it a difficult statute to decipher and apply.”⁶

One major complicating factor in the implementation and regulation of Privacy Act provisions has been the “lack of specific mechanisms for oversight.”⁷ Indeed, some have cited the absence of a central agency for the oversight and coordination of the nation’s privacy matters as a major reason for the ineffectiveness of American privacy laws in general.⁸ In comparison, several other nations have dedicated whole departments and appointed high-level officials to oversee their privacy matters.

The Computer Matching and Privacy Protection Act of 1988 (PL 100-503) amended the Privacy Act of 1974 by adding new provisions regulating the federal government’s use of computer matching—the computerized comparison of information about individuals, usually for the purpose of determining the eligibility of those individuals for benefits. The main provisions of the act include the following:

• Give individuals an opportunity to receive notice of computer matching and to contest information before having a benefit denied or terminated;
• Require that federal agencies engaged in matching activities establish data protection boards to oversee matching activities;
• Require federal agencies to verify the findings of computer matching programs before suspending, denying, or otherwise “adversely” affecting an individual’s benefits; and
• Require agencies to negotiate written agreements with other agencies participating in the matching programs.

An amendment to the act that was passed in 1990 somewhat altered the original act’s due process provisions. Specifically, the amendment changed some of the details regarding subject notification of adverse findings and gave data protection boards the ability to waive independent verification of information under certain circumstances.

In December 2000, the Office of Management and Budget (OMB) issued a memorandum reminding federal agencies of the act’s requirements.⁹,10  According to the memorandum, as “government increasingly moves to electronic collection and dissemination of data, under the Government Paperwork Elimination Act and other programs, opportunities to share data across agencies will likely increase.” Therefore, “agencies must pay close attention to handling responsibly their own data and the data they share with or receive from other agencies.”

Computer Security Act and Recent Amendments

The Computer Security Act of 1987 (PL 100-235) addressed the importance of ensuring and improving the security and privacy of sensitive information in federal computer systems. The act required that the National Institute of Standards and Technology (formerly the National Bureau of Standards) develop standards and guidelines for computer systems to control loss and unauthorized modification or disclosure of sensitive information and to prevent computer-related fraud and misuse. The act also required that operators of federal computer systems, including both federal agencies and their contractors, establish security plans.¹¹ Additionally, the law stipulated that agency plans for protecting sensitive information and systems be cost-effective, and most important, it established a standard for risk mitigation. Specifically, the law says that federal agencies must “establish a plan for the security and privacy of each Federal computer system identified by that agency pursuant to subsection (a) that is commensurate with the risk and magnitude or the harm resulting from the loss, misuse, or unauthorized access to or modification of the information contained in such system.”

Government Paperwork Elimination Act

Part of the impetus for federal agencies to move quickly toward electronic government (and therefore authentication, to an extent) is public law. Enacted in 1998, the Government Paperwork Elimination Act (GPEA)¹² both requires federal agencies to move from paper-based to electronic transactions with the public and provides some of the enablers necessary to make such a transition. It also amplifies federal privacy protections regarding sensitive data collected during the electronic authentication process.

Following on the tradition of the Paperwork Reduction Act (PRA)¹³ of 1995, one of the goals of GPEA is to minimize the burden imposed on the public by federal paperwork requirements. More specifically, though, the goal of both the PRA and GPEA is for federal agencies to minimize the information-collection burden on the public, regardless of whether the collection instrument is a paper form, an electronic transaction, or a phone survey.¹⁴ GPEA recognizes the benefits to both federal agencies and the public of moving from paper-based to electronic transactions, including reduced error rates, lower processing costs, and improved customer satisfaction. As a result, GPEA required agencies by the end of Fiscal Year 2003 to provide for the electronic maintenance, submission, or transaction of information as a substitute for paper where practicable. Additionally, the law stipulates that agencies use and accept electronic signatures in this process.

GPEA goes so far as to define the term “electronic signature” and to legitimate the legal force of such signatures in the scope of public interactions with federal agencies.¹⁵ In doing so, federal law and policy help to clear up what has historically been the subject of some debate among federal agencies about what is legally sufficient to “sign” a transaction with a member of the public. Section 1709(1) of GPEA reads:

The term “electronic signature” means a method of signing an electronic message that—(A) identifies and authenticates a particular person as the source of the electronic message; and (B) indicates such person’s approval of the information contained in the electronic message.

It is important to note as well what the definition does not do, which is to specify the technologies or policies that an agency might use to comply with this definition. The OMB implementation guidance to federal agencies cites examples of appropriate technologies—shared secrets such as PINs and passwords, digitized signatures or biometrics such as fingerprints, and cryptographic digital signatures such as those used in PKIs.¹⁶ The OMB guidance does, though, suggest an analytical framework for an agency to use to help determine the risk inherent in the transaction it hopes to automate and which authentication technology might most appropriately mitigate that risk.

GPEA also cleared up what might otherwise have been a contentious debate among federal agency general counsel offices throughout Washington, D.C., by addressing directly the enforceability of electronic signatures. For transactions involving electronic records submitted or maintained consistent with the policy enabled by GPEA and using electronic signatures in accordance with the same policy, neither the electronic record nor the signature is to be denied legal effect just because it is electronic instead of paper. Both Congress and the OMB state that the intent is to prevent agencies or the public from reverting to paper instead of electronic transactions and signatures because of concerns that any subsequent prosecution—in a benefits fraud case, for instance—might be thrown out of court.

One other provision of the law pertinent to the topic of this study relates to the protection of information collected in the course of providing electronic signatures services. Consistent with the fair information practices (described in Chapter 3 of this report) and the Privacy Act, GPEA requires that information gathered from the public to facilitate electronic signatures services be disclosed only for that purpose.

Agency- or Program-Specific Law and Policies

Family Educational Rights and Privacy Act

The Family Educational Rights and Privacy Act (FERPA) of 1974 (20 U.S.C. § 1232g; 34 CFR Part 99) is a federal law designed to protect the privacy of a student’s education records. The law applies to all schools that receive funds under an applicable program of the U.S. Department of Education. FERPA gives parents certain rights with respect to their children’s education records (for example, the right to inspect and review all of the student’s education records maintained by the school and the right to request that a school correct records believed to be inaccurate or misleading). These rights transfer to the student, or former student, who has reached the age of 18 or is attending any school beyond the high school level.

Under the law, schools must also have written permission from the parent or eligible student before releasing any information from a student’s record. Schools may disclose, with notification, directory-type information, such as a student’s name, address, telephone number, date and place of birth, and so on.¹⁷ As schools move toward authentication technologies such as PKI, issues arise as to how FERPA applies.¹⁸

Health Insurance Portability and Accountability Act

The Health Insurance Portability and Accountability Act (HIPAA),¹⁹ or PL 104-191, was passed by Congress and became law in 1996. Its purpose was, among other things, to improve the continuity of health insurance coverage and the efficiency in health care delivery by mandating standards for electronic data interchanges and to protect the confidentiality and security of health information. Title I of HIPAA deals with health insurance access, portability, and renewability (for example, when a worker loses or changes his or her job), while Title II of the act contains what are referred to as the act’s administrative simplification provisions. These provisions fall roughly into three categories: transactions and code set standards,²⁰ privacy standard,²¹ and security standard.²² The privacy standard, along with the security standard, provides rules for legal controls over patients’ medical records.

The process for creating these standards, or rules, has been fairly complicated. Indeed, according to the Department of Health and Human Services (HHS), the process is a “deliberate [one] designed to achieve consensus within HHS and across other Federal departments.”²³ However, in general, once a proposed rule has made its way through several federal groups (such as the HHS Data Council’s Committee on Health Data Standards, advisers to the secretary of HHS, and the OMB), the proposal is published and comments from the public are solicited. These comments, which are also open to public view, are then “analyzed and considered in the development of the final rules.”²⁴

HIPAA is aimed at all organizations that store, process, or transmit electronic health care information through which an individual might be identified. Accordingly, the act applies to virtually all health care organizations, including—among others—health plans (insurers), health care clearinghouses, health care providers (including health maintenance organizations, hospitals, clinics, physician group practices, and single-physician offices), billing agencies, and universities.

HIPAA also provides for serious civil and criminal penalties for failure to comply with the rules. For example, the penalties include fines of up to $25,000 for multiple violations of the same rule in one year, as well as fines of up to $250,000 and up to 10 years’ imprisonment for knowingly misusing individually identifiable health information.

The privacy rule formally defines “protected health information,” which includes individual patient information such as name, Social Security number, address, and so on; and clinical information such as disease, treatment, drugs, test results, and so on. It permits disclosure of this information for necessary treatment, payment, and operations (TPO) functions. For all other uses, especially for fund-raising and marketing functions, explicit authorization from the patient is required. (There are exceptions, such as for military patients and for clinical research, which is largely governed by the informed consent rule.) If information is provided to an organization not covered by HIPAA for TPO functions (such as a bill collection agency), the rule requires explicit business associate (and possibly chain of trust) agreements that make the recipients responsible for HIPAA-specified privacy and security rules.

The original privacy rule issued in December 2000 required collecting and tracking of a consent form signed by all patients that explained the privacy practices of the institution providing care. Subsequently, a technical correction proposed in January 2001²⁵ removed the consent form requirement and replaced it with a privacy notice that does not require a patient’s signature. Several basic rights for patients are provided in the privacy rule: the right to access their records, the right to emend those records, and the right to see what disclosures of their information have been made. Institutions are required to employ a privacy officer, who provides services related to the privacy rights of patients.

Fundamental to the privacy rule are the “minimum necessary” and “need to know” principles. Based on these principles, the rule requires institutions to develop and implement policies and procedures to define formal role-based or user-based access authorization rules, and the security rule requires assurance that these policies and procedures are being followed. Additionally, a common and uniform sanctions policy is required for addressing privacy and security policy violations. Patient privacy has always been important in care institutions; the HIPAA privacy rule formalizes the concept in a legal framework with significant penalties for noncompliance.

There are several complexities in meeting HIPAA regulations. If information-access rules are incorrectly defined, the care process could be adversely affected, an obviously unacceptable trade-off. The roles of care providers in an organization are fluid: nurses working in shifts or filling in, on-call consultants rotating on a weekly basis, medical students on monthly rotations, multiple physicians in consulting or specialty roles, and so on. Practically, it is very difficult to assign roles to a fine access granularity and to implement such a system in mostly vendor-supported and heterogeneous clinical application environments without raising the risks to proper health care.

Managing authorizations and tracking privacy notices are operational changes for institutions, but centrally tracking all disclosures for review by the patient if requested is a difficult and costly problem in large institutions. In the context of an academic medical center, for example, HIPAA remains vague in addressing the matter of information collected for and by clinical trial and other kinds of research. Open questions about educational rounds and HIPAA were addressed in the latest rule making, and there are other questions that may be clarified, but only later. The privacy rule was required to be adopted by April 14, 2003, but it is likely that there will be a gradual culture change in care environments toward better privacy protection.

Regulation of Private Sector Information Management Activity

Electronic Signatures in Global and National Commerce Act

Aimed at eliminating “legal barriers to the use of electronic technology to form and sign contracts, collect and store documents, and send and receive notices and disclosures,”²⁶ the Electronic Signatures in Global and National Commerce (E-SIGN) Act (PL 106-229) became law in June 2000. The act cleared the way for electronic signatures and contracts to carry the same legal significance as that of traditional paper contracts and handwritten signatures.²⁷ Indeed, President Clinton signed the act into law with a smart card.

The E-SIGN Act includes consumer consent provisions that “require information to be made available electronically only after the recipient affirmatively consents to receive the information [in that manner].”²⁸ In fact, recipients must give this consent electronically as well, to ensure that they possess the necessary technological capability (usually Internet access and/or an e-mail account). The act does not specify the use of any particular technological solution; rather, it “leav[es] those choices [up] to the marketplace.”²⁹ However, some critics view this aspect of the act as being a very real disadvantage, fearing a “mishmash of incompatible solutions”³⁰ and a “standards battle that could take years to resolve.”³¹

In 2001, the Federal Trade Commission and the Department of Commerce completed a congressionally mandated study³² on the impact of the consumer consent provisions of the E-SIGN Act. According to the report, the act’s consumer consent provisions seem to be “working satisfactorily.” The report also suggests that “implementation issues [such as signature and authentication standards] should be worked out in the marketplace and through state and federal regulations” rather than by congressional action to “amend the statute.”

Financial Services Modernization Act

The Financial Services Modernization Act of 1999 (commonly referred to as the Gramm-Leach-Bliley Act) repealed long-standing legislation that prohibited banks, securities firms, and insurance companies from venturing into business with each other. Under Gramm-Leach-Bliley, these types of companies may now join to form what the act calls financial holdings companies (FHCs). What this means with respect to personal privacy is that, for instance, a consumer’s bank can now develop a relationship and share information with that same consumer’s insurance company, brokerage firm, credit union, or other financial institution, creating new opportunities to cross-market services.³³ However, Gramm-Leach-Bliley also contains provisions for protecting consumers’ personal information: (1) consumers must be given notice of a company’s intent to share their information with a third party and (2) they must be given the option to decline such information sharing.

Nevertheless, Gramm-Leach-Bliley is viewed by many privacy advocates as being rife with loopholes—to the point of rendering any privacy protections that it spells out moot. For instance, Dan Gillmor, a technology columnist, describes what he views as two major problems with the act:

• Consumers must opt out of information sharing—“that is, [consumers must] explicitly notify the institutions that they [do not] want their data shared—rather than ‘opt in,’ which is to allow data sharing only after a consumer gives his or her permission.”
• “Affiliated companies (such as those under the same corporate umbrella or in joint marketing deals), so broadly defined as to be almost meaningless, are exempt in every respect.”³⁴

Business, on the other hand, takes a different view of Gramm-Leach-Bliley. Indeed, most financial holdings companies, while taking into account the additional resources and time they must allocate to meeting the act’s privacy provisions, see the act as beneficial to their business. As Federal Reserve Vice Chairman Roger Ferguson put it in a recent speech, Gramm-Leach-Bliley offers “opportunities for banking organizations to expand their lines of business and their range of customer services.”³⁵

Nevertheless, there has been recent activity within state legislatures to strengthen or “enhance the protections of Gramm-Leach-Bliley, including requiring actual consent—or opt-in—before information sharing,”³⁶ breeding significant concern among financial firms at the prospect of having to account for up to 50 different state privacy laws along with Gramm-Leach-Bliley.³⁷

Another challenge has been the requirement for banks and financial institutions to notify customers, in readable and understandable fashion, about their privacy policies. Privacy advocates have noted that many of the policy notifications were written in hard-to-understand legal language and/or distributed in a way that did not draw attention to what was being disclosed.

Policy Activity in the Early 2000s

The last couple of years have seen a flurry of activity relating to both authentication and privacy issues. Some of this legislation predated the terrorist attacks of September 11, 2001, but a great deal of the new legislation is a direct result of the perceived inadequacies of government information management practices leading up to the attacks. This and the following section include recently enacted legislation whose implementation continues to be planned.

USA PATRIOT Act

PL 107-56, Uniting and Strengthening America by Providing Appropriate Tools Required to Intercept and Obstruct Terrorism Act of 2001—the USA PATRIOT Act—gives federal officials broader authority to monitor communications and share information.³⁸ Enacted in response to the terrorist attacks of September 11, 2001, the act’s intent is to combat terrorism, and it encompasses among other things criminal and foreign intelligence investigations, money laundering, and alien terrorists. The most salient effects on individual privacy result from the increased surveillance-related empowerment of government agencies.

In general, there are four surveillance mechanisms provided by U.S. law: interception orders, search warrants, pen registers and trap and trace orders, and subpoenas. Interception orders have given authorities a clearly delineated process for eavesdropping electronically on telephone and face-to-face conversations and electronic communications in serious criminal cases. Search warrants allow the search of premises and the seizure of tangible things, including records. Pen registers and trap-and-trace orders surreptitiously identify the source and destination of calls to and from a particular telephone. Subpoenas compel the production of evidence, including physical items and testimony. There are also differing standards of proof for each of these mechanisms, based on whether domestic law enforcement or foreign intelligence agencies are conducting the surveillance.

The USA PATRIOT Act has changed laws governing all four of the mechanisms described above. It permits pen registers and trap and trace orders for electronic communications, as well as for phone conversations, and authorizes nationwide execution of some surveillance-related court orders. Voice mail is treated like stored e-mail, which gives it less protection than telephone conversations. The act allows interception of communications relevant to the investigation of a suspected computer trespasser and permits sneak-and-peek search warrants and delayed (possibly forever) notification of the subject of the search. It also empowers the attorney general to acquire education records relevant to the investigation of terrorist offenses and to collect DNA samples from prisoners convicted of certain terrorism-related offenses.

The act reduces restrictions on foreign intelligence gathering (that is, on U.S. agencies gathering intelligence about other countries and their citizens) within the United States and facilitates information sharing between foreign intelligence and domestic law enforcement agencies. The act eased some of the restrictions on foreign intelligence gathering introduced during the 1970s—it now permits roving surveillance, expands the allowable circumstances for a search or surveillance under the Foreign Intelligence Surveillance Act of 1978 (FISA) (PL 95- 511, 92 Stat. 1783),³⁹ and sanctions court-ordered access to any tangible item held by lodging, car rental, and storage businesses. Roving surveillance means that warrants need not include specific information about the instrument or location of a search. Unlike domestic law enforcement, FISA searches do not require probable cause of criminality; rather, they require only that the target be suspected of being an agent of a foreign government. Information obtained from these searches may be shared with the FBI. Likewise, domestic law enforcement agencies may also share certain information (e.g., criminal wiretap results) with foreign intelligence agencies.

The USA PATRIOT Act also addresses the financial aspects of terrorism, particularly money laundering. It requires financial services professionals to file suspicious activity reports (SARs) in certain circumstances and also increases “special measures” and “due diligence requirements” related to foreign money laundering. As a result of the act, standards for customer identification and record keeping have become more stringent, and financial institutions are being encouraged to share information with law enforcement agencies.

E-Government Act

The E-Government Act of 2002 (PL 107-347) provides further impetus for the Government Paperwork Elimination Act of 1998 to enable electronic government at the federal level. The act also authorizes increased funding for e-government projects, creates an administrator for a new e-government office within the OMB, extends provisions of the Government Information Security Reform Act of 2000 (PL 106-398, Subtitle G, §1061-1065),⁴⁰ provides uniform safeguards to protect the confidentiality of information collected from the public for statistical purposes, and requires the issuance of government-wide policies for standards for federal Web site usability and for records management for federal Web sites. Especially relevant for this report, the law includes provisions on electronic signature technologies and privacy impact analyses.

The provision concerning electronic signature technologies is intended to promote the compatibility of agency solutions. Executive agencies must ensure that their use and acceptance of electronic signatures to secure electronic transactions with the federal government are compatible with the pertinent policies issued by the OMB. The law further designates the General Services Administration (GSA) as the lead federal agency to create a framework for the interoperability of electronic signatures solutions, which is to include digital signatures.⁴¹

The privacy provisions of the act recognize that more citizen-centered e-government requires an exchange of personally identifiable information between users and federal agencies. In response, the act requires that agencies conduct privacy impact statements when developing or procuring a new information system. While the act leaves the details of the content of privacy impact statements to the OMB to develop, it is reasonable to assume that the OMB will use the best practice of the Chief Information Officers (CIO) Council as a starting point for this policy.⁴²

As of this writing, there are still many implementation details to be worked out, but this new law clearly provides more tools for agencies that seek to implement authentication technologies and to consider the privacy implications of those decisions.

Homeland Security Act of 2002

The Homeland Security Act of 2002 (PL 107-296) establishes a cabinet-level Department of Homeland Security, bringing together a myriad of federal agencies currently spread among a number of federal-level cabinet agencies and executive branch organizations. As a consumer of intelligence data from the FBI and CIA as well as a coordinator of the dissemination of such data throughout the federal government and to state and local governments, the new Department of Homeland Security will have significant information management responsibilities that have both authentication and privacy implications. Much of this information management would appear to fall under the purview of the undersecretary for information analysis and infrastructure protection; the delegation of such responsibilities requires more scrutiny.

Summary

In recent years, the desire for highly integrated electronic government is driving government organizations toward interagency and intergovernmental authentication technology and policy solutions.⁴³ The Access Certificates for Electronic Services (ACES) system, described later in this chapter, is an example of such a proposed solution. However, complications arise when this type of solution is undertaken in the public sector. For example, public sector authentication solutions often involve significant roles for private sector trusted third parties, complicating roles and responsibilities and therefore accountability. In addition, single-sign-on approaches allow interaction with multiple government agencies, but might lead to many of the privacy concerns cited in this report. It is not clear that the current privacy policy framework is sufficiently robust or flexible to provide the privacy protections needed to accommodate these approaches (see Chapter 3 in this report for more on the current state of privacy law and policy in the United States). While there may be a desire for a simple, secure, privacy-preserving means by which citizens can interact with multiple government agencies, it is difficult to satisfy all of these criteria simultaneously. Indeed, as is clear from the discussion in this chapter, privacy law and policy in the United States tend to be without overarching or apparent unifying principles. The lack of cohesiveness in the legal and policy framework could lead to gaps, inconsistencies, and overlaps, making compliance difficult and potentially more expensive.

GOVERNMENT AS ISSUER OF IDENTITY DOCUMENTS

The preceding sections addressed the first role of government, as regulator, and this section discusses its second role with respect to authentication—as an issuer of identity documents, often in conjunction with the private sector. Anyone who has traveled on a commercial airline since September 11, 2001, has a sense of the unique role that government fills in issuing identification documents. The airlines, enforcing regulations issued by the federal government, are quite clear in their instructions; passengers must present a “government-issued photo ID.”⁴⁴ A photo ID issued by a traveler’s employer is not sufficient. It must be government-issued. The government is able to compel individuals to hold certain IDs and follow specified processes in order to help ensure the integrity of the ID issuing process. As a result, government-issued IDs are presumed to be of higher quality than those issued by private organizations (although fraudulent government IDs are demonstrably not hard to come by). (See Box 6.1 for a general discussion of credentials presented by those wishing to be authenticated.)

The integrity of any authentication system that relies on a government-issued identifier depends on the integrity of a small number of foundation ID documents issued by government organizations. What is somewhat surprising, though, is how circular the process of either obtaining, getting a duplicate, or even retiring a government-issued ID is and how involved in the process the private sector is. As discussed below, hospital staff play an integral role in recording birth information that is used for the issuance of birth certificates and then Social Security numbers. It is also possible to get printed copies of birth certificates from private sector companies working on behalf of local governments.⁴⁵ At the other end of the continuum of life, private funeral directors often issue death records for sharing with a variety of government organizations.

The first identity document issued for most native-born U.S. citizens is a birth certificate. Birth and death records are maintained by municipal governments. Many births (all of those outside public hospitals) occur without the presence of any government employee. Many a new parent has faced the admonition from hospital staff not to leave the hospital without naming the new child, making it possible for the city or county office of vital records to record the birth and issue a birth certificate. In the case of a small local government, a town clerk may serve this function. It is interesting to note, however, that the hospital staff play a role in documenting the birth for purposes of establishing the identity of the child and his or her relationship to its parents. A delivery room nurse and the physician who delivered the child are likely to sign the paperwork necessary to obtain the birth certificate. The presence of a nonmedical government employee during childbirth would, in fact, probably be considered to constitute a significant invasion of privacy.

It is also important to note that not all births occur in hospitals. Besides the proverbial delivery in a taxicab, one must consider home births and so on. The U.S. Constitution defines anyone born in the United States as a citizen, whether or not he or she is born in a hospital (at the time the Constitution was written, far fewer children were born in hospitals), so that (hypothetical) controls on birth certificates based on hospital licensing would miss some number of children. In effect, the issuance of a birth certificate approximates the issuance of an identity certificate at birth.

In the past, human witnesses could serve to authenticate someone’s identity in the way that the birth certificate is meant to do now. Children tended to be born at home, in the presence of witnesses from the local community. They grew up among family and neighbors, many of whom remained available for later testimony as to the identity of the eventual adult. In other words, family and neighbors could testify to continuity of identity despite biometric changes in the identified person. The current birth certificate is meant to serve as a substitute, but it has several flaws of its own.⁴⁶

There is, of course, a human element in the issuance procedure, so there are errors both of commission (for example, not accounting properly for stillborn children or creating fraudulent documentation of a “birth” that never occurred) and omission (childbirths that go unrecorded).⁴⁷ As in all automated systems, there must be a manual process for handling these errors, and the impact of the errors must be considered. In addition, in order to ensure that the document refers to the correct individual when it is issued, it is important to issue the initial identity document as close to birth as possible. This begs the question of whether biometrics of some sort are needed, which raises some interesting problems with respect to the many biometrics (including footprints, which are standard in some locales) that might be used as part of an identity document for a small child. Photographs of newborn infant faces are difficult to use for anything other than determining the race of the child, if that. Eye color changes over the first year of life, and newborns have not yet acquired their permanent hair color. While fingerprints are set at birth, there are some important technical limitations: the ridges are so close together that a standard 500-dots-per-inch scanner does not have enough resolution to scan them accurately, and today’s algorithms do not handle finger growth, which causes the ridges to spread farther apart.

The Social Security Administration (SSA) has some nearly unique technical requirements for its system of authenticating people. Parents are given a strong incentive to get an SSN for their child before filing the first federal income tax return after the child’s birth: They must do so to claim the child as a dependent (this is a relatively recent change). Hence, the SSN is likely to be issued near the time of birth. While some children have large enough unearned incomes to require paying taxes, many children will have no use for their SSN until they are teenagers getting their first summer jobs. The first technical requirement, therefore, is that although the binding between a person and his or her SSN will sit dormant for approximately 15 years, it must routinely be verifiable at that later time. Very few commercial systems have this property: If they have not interacted with a customer for 15 years, very few, if any, businesses are required (or want, for that matter) to keep that customer record. Until recently, most people had little or no contact with the SSA during their working years. Now, people receive annual account statements (previously called Personal Earnings and Benefits Estimate) from the SSA. If the statement is correct, there is no need for follow-up, so individuals may still go three to four decades between their first contributions and their next interaction with the SSA, when they claim benefits after retirement. Hence the second technical requirement: The authentication technology needs to work with absolutely minimal interaction over spans of 50 or more years.⁴⁸ This requirement suggests that authentication systems that must persist for long periods of time will have to support renewal, as systems (presumably) change over time.⁴⁹

A third technical requirement for the SSA system of authenticating people is that the system must work for the entire population, not just a significant percentage. As interaction with the SSA, the IRS, and other government agencies is legally mandatory, not being able to authenticate to them is not an option. Either the authentication system must work for everyone (for example, ruling out biometrics that have significant failure rates for reasons beyond people’s control), or there must be a non-onerous exception mechanism. Declaring that certain sets of people are not worth serving (or going to great lengths to serve) is an option in most commercial contexts, but not for the government. If the choice is to include an exception mechanism, it will need to be designed in from the beginning, and the security implications of the exception mechanism will need thorough analysis, since experience indicates that security problems are often found in little-used parts of systems.

Finding 6.2: Electronic authentication is qualitatively different for the public sector and the private sector because of a government’s unique relationship with its citizens:

a. Many of the transactions are mandatory.

b. Government agencies cannot choose to serve only selected market segments. Thus, the user population with which they must deal is very heterogeneous and possibly difficult to serve electronically.

c. Relationships between governments and citizens are sometimes cradle to grave but characterized by intermittent contacts, which creates challenges for technical authentication solutions.

d. Individuals may have higher expectations for government agencies than for other organizations when it comes to protecting the security and privacy of personal data.

This finding echoes the analysis in CSTB’s 2002 report Information Technology Research, Innovation, and E-Government,⁵⁰ which described special considerations in e-government. Ubiquity (access for everyone, anywhere, anytime) and trustworthiness (citizens will not tolerate unauthorized or accidental disclosure of personal information) were described as areas in which government leads in demand for technologies.

The Tangled Web of Government-Issued Identity Documents

It is overly simplistic to view government as monolithic. It may turn out that each agency picks its own authentication technology and deploys it among the user base that the agency serves. Some agencies may voluntarily agree to use another agency’s authenticators. In fact, most models of e-government presume a degree of integration among government agencies and between levels of government.⁵¹,52  Making such electronic interactions work seamlessly for users will require a degree of interoperability for both policy and technology. To this end, as noted in the discussion of the E-Government Act, the federal government is sponsoring the deployment of a PKI that will authenticate transactions across the federal government and (potentially) with state governments as well. In many cases, the government will both issue and rely on the authenticator. As discussed below, once an individual has one of the widely recognized government-issued IDs, he or she can obtain other government-issued IDs. In essence, government acts as a certificate authority (CA) of sorts in the issuance of these documents. (Figure 6.1 illustrates the interdependencies of foundational identity documents.)

Issuance of an SSN requires proof of age and of citizenship or appropriate noncitizen status and a current proof of identity. For adults, the proof of identity is generally another government-issued photo identification, although it need not be: nonphotographic government records such as marriage and divorce records and adoption records are also accepted. Additionally, some private sector identification cards are accepted: for example, employer and school ID cards (usually with photographs), along with insurance policies and ID cards (usually without photographs). For a child, proof of identity is based on a parent’s vouching for the child’s name, possibly indirectly through the hospital’s registrar and/or county/state officials.

A California state ID card (for identification purposes, equivalent to a driver’s license), for example, is issued upon presentation of a birth certificate, passport, or expiring ID card and proof of SSN. As noted earlier, it is difficult to link the birth certificate to the person applying for the ID card. In the United States, state ID cards are the dominant form of photo identification. Most private organizations rely on state ID cards for everyday transactions—for example, paying by check, setting up a video rental account, and so on.

Acquiring a U.S. passport requires a birth certificate, a prior passport or other proof of citizenship, and current proof of identity—that is, a local, state, or federal government-issued photo identification, including state ID cards and U.S. passports. An SSN must be stated on the passport application. The passport is sufficient to request any of the three other forms of identification. In addition, a passport is sufficient proof of identity and authorization to satisfy the U.S. Department of Justice I-9 form.⁵³ Alternatively, the I-9 is most commonly satisfied with a state ID card and a Social Security card. Other possibilities (for example, other military or government ID cards) also exist but are used relatively rarely. Most large employers will issue their own photo identification, which is occasionally used outside the place of employment—for example, for verifying eligibility for various corporate discounts.

The forms of identification described above have several noteworthy features. Birth certificates are generally issued by municipal jurisdictions, state ID cards by states, and Social Security cards and passports by different agencies within the federal government. Weaknesses in various documents, particularly the difficulty of binding a birth certificate to a specific person, are addressed by the business practices of the various agencies. In general, a birth certificate alone is insufficient evidence for the generation of other identity documents. In the United States, each agency has its own policy for what it accepts, while in Australia this concept has been formalized in the “100 points of proof” model.⁵⁴ The formalization occurs through the assignment of points to different identifying documents. For instance, a current Australian passport is worth 70 points, a bank statement is worth 40 points, and employment records are worth 10 points. Different services require different point totals. The decentralized nature of this arrangement means that no single entity has a completely authoritative database. The evidence required for the initial government-issued identity document, the birth certificate, is often attested to by private sector employees. It should also be noted that the United States is a nation of immigrants—documents prepared overseas may introduce even more uncertainty into the system.⁵⁵ All of these factors contribute to the difficulty that the relying party may have in verifying the documents.

As the authentication environment changes over time, with fewer people to attest to the provenance of a person and more and more authentication happening electronically, it will be necessary to revisit the security of foundational identity documents. Today’s systems have worked reasonably well, but it will become increasingly easy for correlated information about an identity to be acquired by someone with malicious intent. For many purposes, birth identity becomes largely irrelevant later in life. Birth certificates, which are bearer credentials, suffer from the problems inherent in all bearer credentials. However, stronger alternatives, such as DNA, are very expensive, may be unpopular with large segments of society, and raise new privacy and technical challenges.

Recommendation 6.1: Birth certificates should not be relied upon as the sole base identity document. Supplemented with supporting evidence, birth certificates can be used when proof of citizenship is a requirement.

Threats to Foundational Documents

As noted previously, government-issued identity documents are the foundational documents relied upon by many authentication systems in both the public and private sectors. Any analysis of such systems must therefore take into account the threat model faced in the issuance and use of those documents.⁵⁶ Only after the threats against the relied-upon documents are understood can the threat faced by the system under analysis be considered. As discussed in Chapter 4, in order to evaluate the security of any authentication system, one first needs to define the threat faced by the system.⁵⁷

The attacks against generation systems for traditional foundational document fall into these general categories:

• Obtaining a fraudulent identity document,
• Passing off someone else’s valid identity document as one’s own,
• Modifying the contents of a valid identity document,
• Compromising private information stored in a back-end system, and
• Unauthorized modification of information stored in a back-end system.

Motivations for these attacks can vary, of course, ranging from the desire to purchase alcohol when under age to the desire to move easily through security checkpoints in order to perpetrate a terrorist act. Attacks could be aimed at individuals (as in the case of identity theft) or at undermining public and private institutions. The disparity of possible motivations highlights another way (see Chapter 4) in which secondary use is dangerous: Namely, it makes it difficult to determine the danger posed by a security breach or attack. Given the myriad uses of driver’s licenses, for example, it is incredibly difficult to ascertain the danger from a successful attack against a motor vehicles department database. Each of these attacks is discussed in more detail below.

• Fraudulent identity documents. These are a major problem in today’s systems. The problem includes both external threats (for example, someone getting a driver’s license with someone else’s birth certificate and SSN) and internal threats (for example, a corrupt clerk at the DMV issuing driver’s licenses without checking supporting documentation). It is worth noting that this kind of fraud happens only on a small scale (in terms of the percentage of identity documents issued), but it is a relatively easy way for a determined person to circumvent the system.
• Imposters. One can attempt to pass off someone else’s identity document as one’s own. Regardless of how the identity document is acquired (for example, a driver’s license stolen in transit or a lost wallet found on the beach), the technical problem is the binding of the document to its holder. Photo identification represents a primitive biometric aimed at solving this problem. It has the advantages of being self-contained and requiring no infrastructure to support verification. The problem is that faces can change dramatically over time, and some identity documents have long lives (for example, with automatic renewal, the picture on a driver’s license can easily be 8 or more years old).
• Document modification. Identity documents may be fraudulently altered (for example, the substitution of photographs on a passport or driver’s license). Preventing this sort of attack requires technical measures in the identity document (for example, holograms on driver’s licenses or embossed seals on passport photos). Document modification is an attack on the integrity of the document itself; in the digital world, cryptographic integrity techniques such as message authentication codes (MACs) and digital signatures, when properly used, provide strong protection against such attacks.
• Compromising confidential information. Many information systems store confidential personal information that is not physically present on the identity document. For example, California and New Jersey driver’s licenses show only the mailing address of their holder, not the street address, if two different addresses are on file. However, an attacker compromising the relevant database could learn the street address of any license holder.
• Modifying computerized records. Given that most identity authentication systems have computerized data records and that additional information may be stored in those systems, one also must be concerned about modification of that information. For example, driver’s license suspensions in some states are handled by electronically marking the appropriate record as having suspended driving privileges, while the license holder is permitted to retain the physical license (and hence to continue to use it as state-issued photo identification—for example, for cashing checks). If an attacker changed this flag, either someone could drive who should not be driving, or someone innocent could be caught driving with a supposedly suspended license. The back-end database, not the physical document, is the arbiter of license status.

Moving to digital credentials will not change these basic categories of fraud. Depending on the technology chosen for authentication, the distribution of fraud among these categories may change. For example, the use of cryptographic integrity techniques for digital credentials would make document modification extremely difficult, if not impossible, assuming that the technology is properly implemented.

A major change between traditional authentication and digital authentication is the scale of likely fraud. With today’s systems, one of the primary weaknesses relates to the validity of a specific instance of an identity document and permeates all of the first three categories above (fraudulent documents, imposters, and document modification). However, controls generally work well enough to prevent the widespread dissemination of fraudulent identity documents. As we move forward into a world of digital identity documents, the issuing process is still extremely important. All the cryptography in the world cannot overcome weakness in this step, because cryptographic notions of trust (and validity) are necessarily relative: They can only be as trustworthy (in the best case) as something else. The hope is that this trust chain is firmly anchored by a statement acknowledged as true in the real world. It is unfortunate that all too many people (including those who should know better) have a tendency to trust as accurate anything that the computer says, even in situations where they would not trust a paper document.

The ability to generate fraudulent identity documents on a small scale tends to have a minor impact on the overall system. However, in a digital world, the compromise of secret information—for example, of a signing key or other methods of accessing the document-issuing system—could open the way to massive issuance or use of fraudulent identity documents. The compromise of back-end systems today is already a problem for the last two categories of threats (compromising information and modifying records). One has to consider the difference in speed of propagation of security breaches. Electronic issuance of identity certificates can go orders of magnitude faster than the issuance of paper-based identity certificates.

Finding 6.3: Many of the foundational identification documents used to establish individual user identity are very poor from a security perspective, often as a result of having been generated by a diverse set of issuers that may lack an ongoing interest in ensuring the documents’ validity and reliability. Birth certificates are especially poor as base identity documents, because they cannot be readily tied to an individual.

Finding 6.4: Scale is a major factor in the implications of authentication for privacy and identity theft. The bulk compromise of private information (which is more likely to occur when such information is accessible online) or the compromise of a widely relied on document-issuing system can lead to massive issuance or use of fraudulent identity documents. The result would adversely affect individual privacy and private- and public-sector processes.

Recommendation 6.2: Organizations that maintain online-accessible databases containing information used to authenticate large numbers of users should employ high-quality information security measures to protect that information. Wherever possible, authentication servers should employ mechanisms that do not require the storage of secrets.

GOVERNMENT AS RELYING PARTY FOR
AUTHENTICATION SERVICES

Government, in addition to issuing identity documents, is also a relying party (that is, it makes payments, allows access to records, and distributes benefits electronically based on claims made by users) for authentication systems to administer public programs at all levels (federal, state, and local). In fact, the government faces some unique challenges as a relying party, owing to its large size and multifaceted nature. It should be noted that government revenues and expenditures are an order of magnitude larger than those of the largest private corporations in the United States. The government’s customer base is everything from an individual citizen to neighborhood nonprofit organizations to large, multinational corporations. In some cases, the interactions between government and varied customers are for the same purpose—for example, paying income taxes. In other cases, the interactions are very different—for example, military procurements tend to come from government contractors, not from private citizens.

Additionally, the functions of government are spread among a multitude of federal, state, county, and local agencies. Government units are organized by function (health and welfare, defense, education, public works, and so on), regardless of how people might interact with them. For example, a small businessperson such as a farmer probably has interactions and transactions with several agencies within the federal government—the Department of Agriculture, the Internal Revenue Service, the Department of Labor, and perhaps the Small Business Administration. At the state level, state tax, labor, and agriculture agencies may have their own set of reporting requirements and benefits but may also pass along some programs funded by the federal government.

There is a belief, held mainly by information technology and public administration professionals, that applications of technology through e-government could reorient public organizations, causing them to become more responsive to the needs of users.⁵⁸ As discussed earlier, GPEA is driving federal agencies to move information and transactions to the Internet. For many public sector organizations, though, the move to e-government was already under way before the enactment of GPEA gave statutory impetus to federal agency efforts. Through the Office of Management and Budget, the federal government has identified 24 e-government projects that might offer a variety of electronic services between government and citizens, government and business, and government and government (that is, between federal, state, and local governments), and several administrative efforts that are for internal use in federal agencies.⁵⁹ For the most part, the task force that recommended this list to OMB found that these efforts had been under way for some time and predated GPEA.

Cutting through the organizational complexity, though, requires a degree of consistency in policy, management, and technology that is rarely found in the paper-based world. Many government agencies, most notably some leading federal agencies, are investing heavily in PKI as the means to deploy an electronic authentication system that will work universally for users of government programs.

The next three subsections describe ways in which the government has tried to authenticate citizens in different contexts. The first is a detailed discussion of a program—Access Certificates for Electronic Services (ACES)—that the federal government had endorsed as a way to authenticate users across a variety of program and organizational lines, the second describes the Internal Revenue Service’s electronic tax filing programs, and the third describes the Social Security Administration’s attempt at remote authentication for access to earnings and benefits statements. Brief concluding remarks follow.

Access Certificates for Electronic Services

ACES is a program instituted by the GSA. The program’s primary purpose is to provide a PKI to facilitate secure online citizen transactions with government agencies.⁶⁰ Under ACES, a user acquires a public key certificate by interacting with one of a small number of selected, commercial CAs. These CAs commit to certification policies and procedures consistent with a model established by GSA for this purpose. This procedure is intended to ensure uniform quality of user authentication and status checking for federal agencies that act as relying parties—that is, that accept these certificates to identify users.

The user employs a certificate issued by an ACES-approved CA and the corresponding private key when engaging in transactions with participating government agencies. Federal agencies developing PKI-enabled applications are encouraged to take advantage of the Certificate Authentication Module (CAM)—a GSA-supplied and Mitretek-developed software—to verify an ACES certificate prior to use. The CAM is designed to perform the requisite certificate validation checks, relieving application developers of the need to implement this complex PKI software. The CAM always verifies the revocation status of an ACES certificate by contacting an Online Certificate Status Protocol (OCSP) server operated by the CA that issued the certificate. (The rationale for adopting this specific revocation-status-checking mechanism is described later.)

To acquire a certificate, a user provides a CA with some personal information to verify the user’s claimed identity. The standards for this verification are established by GSA and thus are uniform for all of the CAs providing the service (within the procedural security limits that these CAs enforce). The form of identity established through this interaction is a name.

The identification provided by this type of interaction generally will not be sufficient to identify the user uniquely to a government agency, since many users may share the same name—for example, John Smith. Thus, ACES certificates generally will be ambiguous relative to the ID requirements for any government agency. An agency may identify a user on the basis of both a name and an SSN or other parameters (for example, home address, age, birth date, and so on.) Thus, when the user contacts an agency for the first time with his or her ACES certificate, the user will need to provide this other information to an agency server to establish the correspondence with the user’s record in the agency database. If this is the user’s first contact of any form with the agency, the agency will need to verify the supplied information as, for example, the SSA does by consulting with other government records. This procedure needs to be repeated by the user when he or she initially contacts an agency. Each agency must then find a means for binding the ACES certificate to the user identity in that agency’s database—for example, on the basis of the CA name and serial number of the certificate or a hash of the public key from the certificate. (The CA name and serial number are unique to the user, but they will change whenever the user renews the certificate, because a new serial number must be assigned to every certificate issued by the CA, even if the user merely renews the certificate. This procedure suggests that users may have to reauthenticate themselves periodically to each agency when the user’s certificate expires, using whatever means the agency employed to effect the initial binding between an ACES certificate and its records. If the hash of the public key of the certificate is employed, similar problems arise whenever the user changes his or her key pair.)

Under the terms of the ACES program, neither the user nor the government pays the CA for issuing an ACES certificate. Instead, every time an individual uses a certificate in a transaction with a government agency, the agency pays. The government agency pays the issuing CA for the revocation status check (via OCSP, usually invoked by the CAM), thus providing the financial motivation for CAs to issue these certificates. ACES avoids the need for government agencies to make up-front investments in establishing a PKI to support this sort of e-government service. It also avoids the need for these agencies to act as CAs. Instead, the agencies pay for the PKI on a sort of installment basis, indefinitely. (This arrangement is analogous in many ways to the government allowing a private company to build a toll road and then collect the tolls, forever.)

It has been suggested that ACES is an appropriate way to enable citizen e-government because the technical aspects of CA operation exceed the capabilities of most government agencies. However, since the certificates issued by the CAs are not sufficient to identify individuals uniquely relative to agency database records, each agency ultimately acts as a registration authority (RA) when it establishes the correspondence between the certificate holder and the database records. The RA function, while less technical than that of the CA, is usually the most security-critical procedure of CA operation, so agencies have not avoided the need to participate in PKI management as a result of ACES. Arguably, the agencies have databases that are ideal for identifying their users to the granularity required to ensure authorized access to records and to effect authenticated transactions. Thus, the use of commercial CAs to issue user certificates does not relieve government agencies of the burden of performing this security-critical function. It is true that CA operation does require specialized technical capabilities, and the ACES program avoids the need for agencies to acquire these capabilities. However, it is not clear that an agency with the IT resources needed to create and operate PKI-enabled applications could not also operate a CA for the users that it serves by means of these applications.

The Internal Revenue Service—Electronic Tax Filing

The IRS has been working to increase the volume of the electronic filing of individual tax returns since the program began in the late 1980s. While IRS e-file has been described as a pioneer program in electronic government, it is interesting to note that for many years the IRS required that electronically filed returns be accompanied by paper signature documents. Only since 1999 has the IRS begun to make the e-file program a totally paperless process, including electronic authentication, for some selected taxpayers.

Fortunately for the IRS, there is public law and policy that supports electronic authentication. The basic requirement in the Internal Revenue Code is that tax returns be signed. However, the law does not specify what constitutes a signing and, in fact, Treasury regulations give the IRS commissioner broad discretion to determine what constitutes a signing. Additionally, the IRS Reform and Restructuring Act of 1998 (PL 105-206) speaks directly to the issue of electronic signatures and provides that they are criminally and civilly equivalent to paper signatures.

There is only one direct channel for the public to e-file with the IRS. Through the Telefile program, the IRS “invites” taxpayers to participate by getting a specially designed tax package. Invitations go to taxpayers on the basis of expected eligibility (as a 1040EZ filer, with income less than $50,000, or as a single filer with no dependents). The package includes instructions for how to file using a Touch-Tone phone and a customer service number (CSN), which is a four-digit PIN. IRS relies on the CSN used by the taxpayer to sign the return, but that does not authenticate the transaction, since the CSN is not a unique identifier. The IRS authenticates the transaction by comparing data elements—the CSN, date of birth, taxpayer identification number (generally an SSN), and a name presented by the taxpayer—to those same data elements maintained in IRS databases.

What makes authentication for IRS e-file somewhat challenging is the role of intermediaries between the IRS and the taxpayer. In addition to the direct provision of service through Telefile, the IRS relies extensively on intermediaries to deliver its electronic filing products to the public. Generally, over half the individual tax returns filed with the IRS are prepared by tax preparers such as commercial services, certified public accountants, and enrolled agents. Tax preparers do an even larger percentage of the returns prepared for e-file, a program that emerged out of a partnership between the IRS and H&R Block. A subset of preparers, authorized e-file providers, are authorized to e-file individual tax returns for their clients. The authorization, in this case, refers to the fact that the IRS regulates the preparers that can e-file in some detail.

Prior to 1999, the only way for a taxpayer to sign a return filed through a preparer was to fill out a paper signature document, called a jurat, which the preparer also had to sign and then send to the IRS within 48 hours of the IRS accepting the return electronically. The requirement for the preparer to file the jurat with the IRS is contained in IRS Revenue Procedures governing the behaviors of authorized e-file providers, which also require them to exercise due diligence in verifying the identity of taxpayers by requesting forms of identification to help validate claimed identity. Similarly, the taxpayer who used personal computer or Web-based tax preparation software prior to 1999 had to complete a jurat and send it to the IRS after the return was acknowledged as accepted. (As a side note, the return can only be transmitted to the IRS through a third-party transmitter authorized by the IRS.)

Beginning in 1999, the IRS built on experience of the Telefile program to issue e-file customer numbers (ECNs) to those individuals who had filed their returns using Web-based or personal computer tax preparation software the previous year. Much as with Telefile, these selected taxpayers got a sealed postcard that explained program eligibility and contained one CSN (two for joint filers).

As part of a parallel pilot in 1999, those taxpayers using an authorized e-file provider could avoid the use of a jurat. In the presence of the preparer, taxpayer(s) would select their own PIN(s), to be used to sign the return. IRS Revenue Procedures required that the taxpayers physically enter their self-selected PINs on the preparer’s keyboard. As part of the signing process, the preparer and taxpayers also record the PIN(s) and other data from the return on a worksheet that both the preparer and taxpayer(s) retain.

In both of the 1999 electronic signature efforts, much as with Telefile, the IRS used the PIN-like four-digit number (for example, CSN, ECN, self-selected PIN) to sign the returns. This procedure meets the legal requirement for a return to be signed. Used in combination with other data presented by the taxpayer(s), the IRS is able to authenticate the transaction to ensure that the taxpayer is who he or she claims to be. The need for such authentication results from the use of a four-digit PIN that is not a unique identifier. Additionally, authentication beyond the signing of the return is necessary because of the business risks associated with refund fraud. The IRS refers to the need for “revenue protection.”⁶¹ Since the initial offering in 1999 and 2000, the IRS has evolved its electronic authentication efforts for taxpayers filing from home using the Web, tax preparation software and/or the services of a tax preparer. The primary difference now is that the IRS no longer mails out the ECN to home filers and instead allows taxpayers to self-select a PIN for signing purposes. Additionally, the signing is bound to the transaction by the taxpayer(s) providing information from the previous year’s tax return like Adjusted Gross Income (AGI) so the IRS can validate claimed identity of the taxpayer beyond name, address, and taxpayer identification number.

The Social Security Administration and PEBES

One of the more infamous cases of privacy involving authentication colliding with e-government capabilities comes from the SSA’s Online PEBES initiative.⁶² In 1997, the SSA had to bring down its otherwise-successful Web-based capability allowing individuals to request and ultimately receive a Personal Earnings and Benefits Estimate Statement (PEBES) over the Web. The SSA took this action after a USA Today article and subsequent stories in other national news outlets raised concerns about the how the SSA authorized the release of a PEBES to an individual electronically (described below). Although PEBES provided dramatically improved service through reduced cycle times and cost per transaction, SSA yielded to congressional pressure and suspended the service owing to the public outcry resulting from the national media coverage.

Historically, SSA had provided PEBES to those who made a request over the phone or by mail if the requester produced three identifiers (SSN, date of birth, and name), without validating if the requester was really the person related to that record. For instance, it was quite possible that a wife could have provided the requested information and obtained her husband’s PEBES using that business rule. Using this process, SSA filled literally millions of requests per year for PEBES by mail and over the phone.

To improve service and reduce the workload of the shrinking SSA staff, the organization launched an effort to fulfill requests for PEBES through a self-service application over the Web. Initially the SSA provided partial electronic service, taking the request electronically but reverting to paper by mailing the report to the address provided in the request. Over time, and after considering the results of pilot testing and some risk analyses, the SSA launched the fully interactive version by which the PEBES was delivered back to the requester electronically. As an acknowledgment that moving this kind of transaction (even just the PEBES request portion) to the Web might entail more risk, the SSA added more data elements to the identifiers used in the knowledge-based authentication that had been used for the previous 25 years. The Web-based self-service application would now require the requester to provide place of birth and mother’s maiden name in addition to the three elements listed above.

The fully interactive PEBES was up for approximately 1 month before the press depicted the offering as “social insecurity.” The concern expressed by the press and by several senators who wrote to the commissioner of the SSA soon after the story broke was that the data elements used in the knowledge-based authentication system might well be known to people other than the owner of the data (and of the related PEBES report). More than even disgruntled spouses (or ex-spouses), close friends or other individuals who might be able to assemble the required data elements could gain access to the PEBES that they were not entitled to.⁶³

The three examples—ACES, the IRS and electronic tax filing, and the SSA and PEBES—illustrate the complexity of authentication and security requirements and privacy. The IRS and the SSA have different threat models and different security and privacy requirements, demonstrating once again that monolithic solutions, even at the federal level, are unlikely to be satisfactory.

NATIONWIDE IDENTITY SYSTEMS

The federal government is not the only government body that plays a role in authentication and privacy considerations. It is through local governments that most individuals acquire identification documents. State governments also play a key part in individual authentication—for example, in the issuance of driver’s licenses by state departments of motor vehicles (DMVs). The committee’s first report, IDs—Not That Easy,⁶⁴ examined the concept of a nationwide identity system, raising numerous policy and technological questions that would need to be answered if such a system were to be put into place. In such a hypothetical system, government would likely fill all three roles: regulator, issuing party, and relying party.

As noted in IDs—Not That Easy, state driver’s licenses already constitute a large-scale (nationwide and, in some cases, international) system of identification and authentication. Earlier in this report, it was noted that secondary use of state driver’s licenses and state IDs raises significant privacy and security concerns. Recognizing the ease with which such documents can be fraudulently reproduced or obtained, there have been proposals to strengthen driver’s licenses. The American Association of Motor Vehicle Administrators is in the process of developing and proposing standards to do that.⁶⁵ They include provisions for the use of biometrics to tie a driver to his or her license; some states already require fingerprints. As with any system that uses biometrics, however, care must be taken to mitigate threats against the resulting database.

Finding 6.5: State-issued driver’s licenses are a de facto nationwide identity system. They are widely accepted for transactions that require a form of government-issued photo ID.

Finding 6.6: Nationwide identity systems by definition create a widespread and widely used form of identification, which could easily result in inappropriate linkages among nominally independent databases. While it may be possible to create a nationwide identity system that would address some privacy and security concerns, the challenges of doing so are daunting.

Recommendation 6.3: If biometrics are used to uniquely identify license holders and to prevent duplicate issuance, care must be taken to prevent exploitation of the resulting centralized database and any samples gathered.

Recommendation 6.4: New proposals for improved driver’s license systems should be subject to the analysis presented in this report by the National Research Council’s Committee on Authentication Technologies and Their Privacy Implications and in the earlier (2002) report by the same committee: IDs—Not That Easy: Questions About Nationwide Identity Systems.

CONCLUDING REMARKS

Government organizations, especially federal agencies, must live with a plethora of legal and policy demands and guidelines in the area of authentication and privacy, as well as provide accountability and submit to oversight. While citizens demand ease of use, they also expect security and privacy protection for the information that in many cases they are required to provide to the government. Reconciling this tension is a continuing challenge for any institution, but especially for the government, owing to its unique role and requirements. This report emphasizes the need to avoid authentication or identification when mere authorization will suffice. In the case of government, respecting the legitimate function of anonymity is even more crucial. Given the often obligatory relationship between citizen and government, allowing anonymity and therefore increased privacy protection when possible not only increases efficiency (by avoiding the need to employ complicated authentication machinery before a transaction) but also enables the many advantages of privacy protection described in Chapter 3. (A simple example in which authentication is not required for interaction with the government is the downloading of tax forms. The identity of the person downloading certain forms does not need to be verified before the forms are made available. The same holds true for many public records.)

Finding 6.7: Preserving the ability of citizens to interact anonymously with other citizens, with business, and with the government is important because it avoids the unnecessary accumulation of identification data that could deter free speech and inhibit legitimate access to public records.

E-government is a driver for authentication and privacy solutions that place greater emphasis on government as a relying party than as an issuer of ID documents. Systems that depend on a common identifier in government are subject to the privacy risks associated with the potential for inappropriate data aggregation and (inadvertent or deliberate) information sharing in ways that the individual providing the information did not expect. Care must be taken to adhere to the principles in the Privacy Act of 1974 and the privacy principles described in Chapter 3 of this report.

Finding 6.8: Interagency and intergovernmental authentication solutions that rely on a common identifier create a fundamental tension with the privacy principles enshrined in the Privacy Act of 1974, given the risks associated with data aggregation and sharing.

Finally, while this chapter emphasizes many of the unique constraints under which government must operate, government is not immune to the challenges faced by the private sector when developing authentication systems, many of which are touched on in the preceding chapters. Threat models must be understood before proceeding, and the goals of any authentication system should be well articulated.

Notes

¹One insightful definition of federalism and its complexity comes from Woodrow Wilson: “To make town, city, county, state, and federal government live with a like strength and an equally assured healthfulness, keeping each unquestionably its own master and yet making all interdependent and cooperative, combining independence and mutual helpfulness.” See Woodrow Wilson, “The Study of Administration,” Political Science Quarterly 2(June 1887):197-222, quoted in Dell S. Wright, “A Century of Intergovernmental Administrative State: Wilson’s Federalism, New Deal Intergovernmental Relations, and Contemporary Intergovernmental Management,” A Centennial History of the American Administrative State, Ralph Clark Chandler, ed. New York, N.Y., The Free Press, 1987, p. 220.

²Charles Goodsell. The Case for Bureaucracy, 3rd ed. New York, N.Y., Seven Bridges Press, 1994.

³Government Accounting Office (GAO). Internet Privacy: Agencies’ Efforts to Implement OMB’s Privacy Policy [GGD-00-191]. Washington, D.C., GAO, September 2000. Available online at <http://www.gao.gov/archive/2000/gg00191.pdf>.

⁴The full text of the act itself is available online at <http://www.usdoj.gov/04foia/privstat.htm>.

⁵Text for these three items is adapted from Harold C. Relyea, The Privacy Act: Emerging Issues and Related Legislation, Congressional Research Service (CRS) Report RL30824, Washington, D.C., CRS, Library of Congress, September 2000.

⁶Department of Justice. “Overview of the Privacy Act of 1974” (Introduction), 2000. Available online at <http://www.usdoj.gov/04foia/1974intro.htm>.

⁷Charles R. Booz. “Electronic Records and the Right to Privacy: At the Core.” Information Management Journal 35 (3): 18.

⁸See David H. Flaherty, “The Need for an American Privacy Protection Commission,” Government Information Quarterly 1(3)(1984):235-258. In later work, he also observes that design of the system and policy choices are crucial to privacy protection. See, for example, “Privacy Impact Assessments: An Essential Tool For Data Protection,” presentation to a plenary session “New Technologies, Security and Freedom” at the 22nd Annual Meeting of Privacy and Data Protection Officials held in Venice, Italy, September 27-30, 2000. Available online at <http://www.anu.edu.au/people/Roger.Clarke/DV/PIAsFlaherty.html>.

⁹Office of Management and Budget (OMB). “Guidance on Inter-Agency Sharing of Personal Data—Protecting Personal Privacy,” M-01-05, December 20. Available online at <http://www.whitehouse.gov/omb/memoranda/m01-05.html>.

¹⁰This and related activities at OMB were part of the context that led to this study.

¹¹For the full text of the act, see <http://www.epic.org/crypto/csa/csa.html>.

¹²Government Paperwork Elimination Act of 1998 (PL 105-277, Div. C, tit XVII).

¹³Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35).

¹⁴For background on the goals of GPEA, see Senate Report 105-355, and for background on the PRA and GPEA, see OMB, “Procedures and Guidance; Implementation of the GPEA,” Federal Register, May 2, 2000.

¹⁵For more on electronic signatures, see the discussion of the Electronic Signatures in Global and National Commerce Act (E-SIGN) of 2000 later in this chapter.

¹⁶See the Web site <http://www.whitehouse.gov/omb/fedreg/gpea2.html>.

¹⁷The full text of the act is available online at <http://www.epic.org/privacy/education/ferpa.html>.

¹⁸EDUCAUSE, an organization that promotes information technology in higher education, has looked at this and related issues in its initiative PKI for Networked Higher Education. See the Web site <http://www.educause.edu/netatedu/groups/pki/> for more information.

¹⁹The full text of the act is available online at <http://aspe.os.dhhs.gov/admnsimp/pl104191.htm>.

²⁰Health Insurance Reform: Standards for Electronic Transactions. 45 CFR Parts 160 and 162. Federal Register: August 17, 2000 (Volume 65, Number 160), pp. 50312-50372.

²¹Standards for Privacy of Individually Identifiable Health Information. 45 CFR Parts 160 through 164. Federal Register: December 28, 2000 (Volume 65, Number 250), pp. 82461-82510.

²²Security and Electronic Signature Standards: Proposed Rule. 45 CFR Part 142. Federal Register: August 12, 1998 (Volume 63, Number 155), pp. 43241-43280.

²³From the Web site <http://aspe.os.dhhs.gov/admnsimp/8steps.htm>.

²⁴Ibid.

²⁵Standards for Privacy of Individually Identifiable Health Information; Proposed Rule. 45 CFR Parts 160 through 164. Federal Register: March 27, 2002 (Volume 67, Number 59), pp. 14775-14815.

²⁶OMB. “Guidance on Implementing the Electronic Signatures in Global and National Commerce Act” (M-00-15), September 25, 2000. Available online at <http://www.whitehouse.gov/omb/memoranda/m00-15.html>.

²⁷Electronic signatures, in this context, are not the same as the digital signatures that were described in Chapter 5. One of the critiques of this law is that electronic signatures do not embody the same security methods and principles as digital signatures.

²⁸News Bytes News Networks. “E-SIGN Law Appears to Work Fine So Far—Gov’t Study.” June 27, 2001.

²⁹John Schwartz. “E-Signatures Become Valid for Business.” New York Times. October 2, 2000, p. C1.

³⁰Abby Ellin. “E-Sign on the Dotted Line.” Business 2.0, November, 2000. Available online at <http://www.business2.com/articles/mag/0,1640,8542,FF.html>.

³¹Jesse Berst. “Sign of Trouble: The Problem with E-Signatures.” ZDNet, July 17, 2000. Available online at <http://www.zdnet.com/anchordesk/stories/
story/0,10738,2604099,00.html>.

³²Federal Trade Commission (FTC) and Department of Commerce (DOC). Electronic Signatures in Global and National Commerce Act: The Consumer Consent Provision in Section 101(c)(1)(C)(ii). Washington, D.C., FTC, DOC, June 2001. Available online at <http://www.ftc.gov/os/2001/06/esign7.htm>.

³³Cecelia Kempler and Robert Wood. 2000, “Living with the Gramm-Leach-Bliley Act.” Washington, D.C., LeBoeuf, Lamb, Greene & MacRae L.L.P. Available online at <http://www.insurelegal.com/livingwith031500.html#1>.

³⁴Dan Gillmor. “Gramm-Leach’s Privacy Problem.” Computerworld 35 (30)(2001): 34. Available online at <http://www.computerworld.com/cwi/story/
0,1199,NAV47-74_STO62385,00.html>.

³⁵Roger W. Ferguson, “Umbrella Supervision: Emerging Approaches,” speech before the National Association of Urban Bankers, Urban Financial Services Coalition, San Francisco, Calif., May 26, 2001. Available online at <http://www.federalreserve.gov/boarddocs/speeches/2000/20000526.htm>.

³⁶M. Maureen Murphy. Privacy Protection for Customer Financial Information, Congressional Research Service (CRS) Report for Congress RS20185. Washington, D.C., CRS, Library of Congress, August 2001.

³⁷Indeed, in June 2002, voters in North Dakota approved a referendum that would bar the sale of personal data collected by banks, credit unions, and other financial services firms to third parties. See P. Thibodeau, “N.D. Voters Side Overwhelmingly with Privacy,” ComputerWorld, June 12, 2002.

³⁸See Charles Doyle, The USA PATRIOT Act: A Sketch, Congressional Research Service Report RL21203, and Charles Doyle, The USA PATRIOT Act: A Legal Analysis, Congressional Research Service Report RL31377.

³⁹For more information on FISA, see <http://www.eff.org/Censorship/Terrorism_militias/fisa_faq.html> and the law itself at <http://www4.law.cornell.edu/uscode/50/ch36.html>.

⁴⁰The Government Information Security Reform Act (GISRA) of 2000 required agencies to report annually to OMB on the security of their information systems and to make information system security part of their regular process of doing business (e.g., in budget requests). Under a sunset provision, GISRA was originally intended to expire in November 2002; however, the Federal Information Security Management Act (H.R. 3844), which was later incorporated into the E-Government Act, made the GISRA provisions mentioned above permanent. See Judi Hasson, “Egov Agenda Takes Shape,” Federal Computer Week, December 2, 2002. Available online at <http://www.fcw.com/fcw/articles/2002/1202/news-egov-12-02-02.asp>.

⁴¹ GSA’s Federal Bridge Certification Authority is a move in this direction; for more information, see <http://www.cio.gov/fbca/>.

⁴²See the CIO Council’s Web site for information on the IRS’s implementation of the privacy impact statement as a best practice. Available online at <http://www.cio.gov/documents/pia_for_it_irs_model.pdf>.

⁴³See Computer Science and Telecommunications Board, National Research Council, Information Technology Research, Innovation, and E-Government, Washington, D.C., National Academy Press, 2002, for a broad look at e-government innovation and approaches that can help accelerate innovation in government.

⁴⁴See the Web site <http://www.tsa.gov/workingwithtsa/travel.shtm> for federal rules on government-issued IDs for flying commercially. John Gilmore is presently challenging these regulations in federal court. See <http://cryptome.org/freetotravel.htm> for a chronology of that suit.

⁴⁵See, for example, the Web site <http://www.vitalchek.com/provider_overview.asp> for information on obtaining birth certificates and other vital records.

⁴⁶There are many contexts in which human witnesses serve as verifiers of identity of either people or objects. For example, chains of custody in court cases require human witnesses to testify to the provenance of something admitted into evidence. Human witnesses can, of course, authenticate other individuals; this requires establishing the authority and veracity of the witness. This report does not investigate the pros and cons of human witness testimony, as the committee’s charge was to examine authentication technologies, but certainly there are situations in which human witness testimony may be the best (or only) method available for verifying identity.

⁴⁷There are other randomization processes at work in addition to errors in documentation. It is known, for instance, that on rare occasions parents have taken the wrong child home from a hospital nursery. As discussed already, family mobility is a randomizer for the early childhood years. A child whose parents move frequently while the child is maturing can lose all witnesses to his or her identity continuity except for his or her parents, and if those parents should die or otherwise not be acceptable as witnesses, that child would have no witnesses to identity. As individuals urbanize and become more mobile, if the only method of establishing identity is through human witnesses to identity continuity, it may not be possible to establish identity with close to 100 percent confidence. Put another way, it may be becoming easier for someone to infiltrate an urbanized nation under an assumed identity.

⁴⁸It should be noted that no cryptographic system other than the one-time pad has remained secure for 50 years in modern history.

⁴⁹Note that this may mean more than just changing key sizes, as is done for some authentication algorithms; other cryptographic parts of the system, such as hash functions, may need replacing.

⁵⁰Computer Science and Telecommunications Board, National Research Council. Information Technology Research, Innovation, and E-Government. Washington, D.C., National Academy Press, 2002.

⁵¹For example, see K. Layne and J. Lee, “Developing Fully Functional E-Government: A Four Stage Model,” Government Information Quarterly 18: 122-136, and Janine S. Hiller and France Bélanger, “Privacy Strategies for Electronic Government,” E-Government 2001, Mark A. Abramson and Grady E. Means, eds. New York, Rowman and Littlefield, 2001.

⁵²See also the white paper “Federal Electronic Government Infrastructure: The E-Authentication Gateway—Connecting People to Services,” available online at <http://www.cio.gov/eauthentication/presentations/
authentication_gateway_whitepaper.pdf>.

⁵³The I-9 form is required to be completed by all new employees so that their employer can verify their employment eligibility.

⁵⁴See the Web sites <http://www.centrelink.gov.au/internet/internet.nsf/
multifilestores/poi0110t/$File/poi0110en.pdf> and <http://www.whittlesea.vic.gov.au/enquiries/eserv_user.asp>.

⁵⁵Note the case of Danny Alimonte, born in the Dominican Republic. His eligibility to play Little League baseball came into dispute during the 2001 Little League World Series. It was unclear whether Danny was 12 or 14 years old. Dominican Republic birth records from the mid-1980s yielded inconsistent answers. He was eventually declared ineligible.

⁵⁶This discussion applies as well to the generation of identity documents that does not take place under governmental purview. However, given that in practice many authentication systems do ultimately rely on a government-issued identification document, the discussion is in that context.

⁵⁷It is worth remembering that authentication is often the first step in authorization. The many authorization policies that different government and private sector parties may have are outside the scope of this report. However, from a privacy perspective, it is often better to handle authorization directly, rather than as a function of identity (verified through authentication). For example, one can anonymously watch a movie: one goes to the ticket window, purchases a ticket with cash, gives the ticket to the ticket collector, and enters the theater. No record is ever made of the identity of the moviegoer. On the other hand, many moviegoers voluntarily give up some amount of privacy to purchase tickets with a credit card, possibly beforehand, over the telephone or the Internet.

⁵⁸For some selected visions of e-government, see the National Association of Chief Information Officers, online at <http://www.nascio.org/publications/digital_government_report_2001.pdf>; Council for Excellence in Government, online at <http://www.excelgov.org/usermedia/images/uploads/PDFs/
the_next_american_revolution.pdf>; or OMB e-government strategy, online at <http://www.whitehouse.gov/omb/inforeg/egovstrategy.pdf>.

⁵⁹See the Web site <http://www.egov.gov/egovreport-3.htm> for a more detailed description of these 24 initiatives.

⁶⁰The General Services Administration is a federal management agency that sets policy in areas related to federal procurement, real estate, and information resources.

⁶¹Given that over 70 percent of individual tax returns result in a refund and that there is a history of individuals trying to defraud the government by seeking refunds they are not entitled to, this is a significant business risk. It is interesting to note that the shift from paper-based to electronic signing altered the IRS’s ability to prevent some refund fraud. For instance, the use of the CSN in the case of Telefile and the ECN in the first 2 years of that effort, in conjunction with other identifying data, provides an extra check up-front that is not possible with paper-based signings.

⁶²Zachary Tumin. “Social Security on the Web: The Case of the Online PEBES.” Strategic Computing & Telecommunications in the Public Sector. Boston, John F. Kennedy School of Government, Harvard University, 1998.

⁶³For SSA’s own analysis of PEBES, see “Privacy and Customer Service in the Electronic Age: Report to Our Customers,” available online at <http://www.ssa.gov/reports/service/>.

⁶⁴Computer Science and Telecommunications Board, National Research Council. IDs—Not That Easy: Questions About Nationwide Identity Systems. Washington, D.C., National Academy Press, 2002.

⁶⁵More information is available online at <http://www.aamva.org/IDSecurity/>.