| ||||||||||||||||||||||||||||||
|
||||||||||||||||||||||||||||||
| Copyright © 2009. National Academy of Sciences. All rights reserved. Terms of Use and Privacy Statement |
Below are the first 10 and last 10 pages of uncorrected machine-read text (when available) of this chapter, followed by the top 30 algorithmically extracted key phrases from the chapter as a whole.
Intended to provide our own search engines and external engines with highly rich, chapter-representative searchable text on the opening pages of each chapter.
Because it is UNCORRECTED material, please consider the following text as a useful but insufficient proxy for the authoritative book pages.
Do not use for reproduction, copying, pasting, or reading; exclusively for search engines.
OCR for page 138
6
Authentication, Privacy, and the
Roles of Government
Government institutions play multiple roles in the area where au-
thentication 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, gov-
ernment plays multiple roles in the authentication process. As a relying
party, government uses authentication technologies for electronic gov-
ernment applications and for physical and systems security applications.
Given the size of its workforce and its user base, government is a signifi-
cant user of these technologies. The government's role in the authentica-
tion process (as regulator, issuer, and relying party) is important, since so
many forms of authentication or identification rely on some form of gov-
ernment-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,
138
OCR for page 139
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
139
secondary uses of the SSN have proliferated, beginning with their use by
the Eternal 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 me higher confidence levels
desired by me 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 me SSA to change its SSN issuance and maintenance
processes In order to help me private sector manage business risk around
creditworthiness just because most credit bureaus use SSNs as unique iden-
tifiers for credit history. An examination of the various roles that govern-
ment 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 activi-
ties are assumed to be fair, impartial, and immune from commercial ma-
nipulation.2 This legal and policy context for the government manage-
ment 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
1One insightful definition of federalism and its complexity comes from Woodrow Wil-
son: "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 helpful-
ness." See Woodrow Wilson, "The Study of Administration," Political Science Quarterly
2Qune 1887~:197-222, quoted in Dell S. Wright, "A Century of Intergovernmental Adminis-
trative State: Wilson's Federalism, New Deal Intergovernmental Relations, and Contempo-
rary Intergovernmental Management," A Centennial History of the American Administrative
State, Ralph Clark Chandler, ed. New York, N.Y., The Free Press, 1987, p. 220.
2Charles Goodsell. The Case for Bureaucracy, 3rd ed. New York, N.Y., Seven Bridges
Press, 1994.
OCR for page 140
40
WHO GOES THERE?
such as the questions on census forms. Alternatively, some relationships
with government are straightforward and contractual, just as with a busi-
ness. 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 busi-
ness 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 gov-
ernment 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 behav-
ior, issuers of identity documents or identifiers, and also rely-
ing 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) govern-
ment-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 bound-
aries for transactions such as federally funded health care or higher edu-
cation; 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.
OCR for page 141
OCR for page 142
OCR for page 143
OCR for page 144
OCR for page 145
OCR for page 146
OCR for page 147
OCR for page 148
OCR for page 168
OCR for page 169
OCR for page 170
OCR for page 171
OCR for page 172
OCR for page 173
OCR for page 174
OCR for page 175
OCR for page 176
OCR for page 177
OCR for page 178
Representative terms from entire chapter:
electronic signatures
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
Government-wide Law and Policy
Privacy Act and Computer Matching Act
141
A recent Government Accounting Office (GAO) reports refers to the
Privacy Act of 1974 (5 U.S.C. Sec. 552a)4 as the "primary [U.S.] law regu-
lating 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 exer-
cises rights guaranteed by the First Amendment unless expressly autho-
rized by statute or by the individual about whom the record is main-
tained 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 emen-
dation 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 prac-
tice. For example, it sets certain conditions concerning the disclosure of
personally identifiable information; prescribes requirements for the ac-
counting 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 determi-
nations about an individual's rights, benefits, and privileges under Fed-
eral programs"; requires agencies to specify their authority and purposes
for collecting personally identifiable information from an individual; re-
quires agencies to "maintain all records which are used by the agency in
3Government Accounting Office ~GAO'. Internet Privacy: Agencies' Efforts to Implement
OMB's Privacy Policy [GGD-00-lgl]. Washington, D.C., GAO, September 2000. Available
online at .
4The full text of the act itself is available online at
42
WHO GOES THERE?
making any determination about any individual with such accuracy, rel-
evance, timeliness, and completeness as is reasonably necessary to assure
fairness to Me individual in Me determination"; and provides civil and
criminal enforcement arrangements.5
However, passed in great haste during the final week of Me 93rd
Congress, Me "Act's imprecise language, limited legislative history, and
somewhat outdated regulatory guidelines have rendered it a difficult stat-
ute to decipher and apply."6
One major complicating factor in the implementation and regulation
of Privacy Act provisions has been the "lack of specific mechanisms for
oversight."7 Indeed, some have cited the absence of a central agency for
Me oversight and coordination of the nation's privacy matters as a major
reason for the ineffectiveness of American privacy laws in general.8 In
comparison, several other nations have dedicated whole departments and
appointed high-level officials to oversee Weir privacy matters.
The Computer Matching and Privacy Protection Act of 1988 (PL 100-
503) amended Me Privacy Act of 1974 by adding new provisions regulat-
ing the federal government's use of computer matching the computer-
ized comparison of information about individuals, usually for Me 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 estab-
lish data protection boards to oversee matching activities;
· Require federal agencies to verify the findings of computer match-
5Text for these three items is adapted from Harold c. Relyea, The Privacy Act: Emerging
Issues and Related Legislation, Congressional Research service tCRS' Report RL30824, Wash-
ington, D.C., CRS, Library of congress, September 2000.
6Department of Justice. "Overview of the Privacy Act of 1974~, Introductions, 2000.
Available online at .
7Charles R. Booz. "Electronic Records and the Right to Privacy: At the core. Informa-
tion Management Journal 35 `3~: 18.
8see 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 .
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
143
ing programs before suspending, denying, or otherwise "adversely" af-
fecting an individual's benefits; and
· Require agencies to negotiate written agreements with other agen-
cies 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 find-
ings 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) is-
sued a memorandum reminding federal agencies of the act's require-
ments.9 lo According to the memorandum, as "government increasingly
moves to electronic collection and dissemination of data, under the Gov-
ernment 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 im-
portance of ensuring and improving the security and privacy of sensitive
information in federal computer systems. The act required that the Na-
tional Institute of Standards and Technology (formerly the National Bu-
reau of Standards) develop standards and guidelines for computer sys-
tems 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, includ-
ing both federal agencies and their contractors, establish security plans.ll
Additionally, the law stipulated that agency plans for protecting sensitive
information and systems be cost-effective, and most important, it estab-
lished a standard for risk mitigation. Specifically, the law says that fed-
eral agencies must "establish a plan for the security and privacy of each
Federal computer system identified by that agency pursuant to subsec-
tion (a) that is commensurate with the risk and magnitude or the harm
9Office of Management and Budget (OMB). "Guidance on Inter-Agency Sharing of Per-
sonal Data Protecting Personal Privacy," M-01-05, December 20. Available online at
.
This and related activities at OMB were part of the context that led to this study.
For the full text of the act, see .
44
WHO GOES THERE?
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 elec-
tronic government (and therefore authentication, to an extent) is public
law. Enacted in 1998, the Government Paperwork Elimination Act
(GPEA)12 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 au-
thentication process.
Following on the tradition of the Paperwork Reduction Act (PRA)13
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.l4 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 satis-
faction. 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 interac-
tions with federal agencies.l5 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
Government Paperwork Elimination Act of 1998 (PL 105-277, Div. C, tit XVII).
Paperwork Reduction Act of 1995 (44 U.S.C. Chapter 35~.
14For 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.
15For 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.
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
source of the electronic message; and (B) indicates such person's ap-
proval of the information contained in the electronic message.
145
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 fed-
eral 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.l6 The OMB guidance does, though, suggest an analytical frame-
work 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 Wash-
ington, D.C., by addressing directly the enforceability of electronic signa-
tures. For transactions involving electronic records submitted or main-
tained 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 provid-
ing 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
16See the Web site .
46
WHO GOES THERE?
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.l7 As schools move toward authentication
technologies such as PKI, issues arise as to how FERPA applies.l8
Health Insurance Portability and Accountability Act
The Health Insurance Portability and Accountability Act (HIPAA),l9
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 mandat-
ing standards for electronic data interchanges and to protect the confiden-
tiality 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,20 privacy standard,21 and security standard.22 The privacy
standard, along with the security standard, provides rules for legal con-
trols over patients' medical records.
17The full text of the act is available online at
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
147
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."23 How-
ever, 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."24
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 organi-
zations, including among others health plans (insurers), health care
clearinghouses, health care providers (including health maintenance or-
ganizations, hospitals, clinics, physician group practices, and single-phy-
sician offices), billing agencies, and universities.
HIPAA also provides for serious civil and criminal penalties for fail-
ure 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 Se-
curity 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 mar-
keting functions, explicit authorization from the patient is required.
(There are exceptions, such as for military patients and for clinical re-
search, 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 ex-
plicit business associate (and possibly chain of trust) agreements that
make the recipients responsible for HIPAA-specified privacy and secu-
rity 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 techni-
23From the Web site .
24Ibid.
48
WHO GOES THERE?
cat correction proposed in lanuary 200125 removed the consent form re-
quirement 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 secu-
rity rule requires assurance that these policies and procedures are being
followed. Additionally, a common and uniform sanctions policy is re-
quired for addressing privacy and security policy violations. Patient pri-
vacy has always been important in care institutions; the HIPAA privacy
rule formalizes the concept in a legal framework with significant penal-
ties for noncompliance.
There are several complexities in meeting HIPAA regulations. If in-
formation-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 insti-
tutions. 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 educa-
tional 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 pri-
vacy protection.
25Standards 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.
68
WHO GOES THERE?
ity) 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 an-
chored 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 docu-
ments. 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 propa-
gation 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 certifi-
cates 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 au-
thentication for privacy and identity theft. The bulk compro-
mise 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 pub-
lic-sector processes.
Recommendation 6.2: Organizations that maintain online-ac-
cessible databases containing information used to authenticate
large numbers of users should employ high-quality informa-
tion security measures to protect that information. Wherever
possible, authentication servers should employ mechanisms
that do not require the storage of secrets.
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
GOVERNMENT AS RELYING PARTY FOR
AUTHENTICATION SERVICES
169
Government, in addition to issuing identity documents, is also a rely-
ing party (that is, it makes payments, allows access to records, and distrib-
utes benefits electronically based on claims made by users) for authenti-
cation 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 magni-
tude 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 multi-
tude 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 inter-
actions and transactions with several agencies within the federal govern-
ment 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.58 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 Man-
58For some selected visions of e-government, see the National Association of Chief Information
Officers, online at ;
Council for Excellence in Government, online at
70
WHO GOES THERE?
agement and Budget, the federal government has identified 24 e-govern-
ment 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 agen-
cies.59 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 nota-
bly some leading federal agencies, are investing heavily in PKI as the
means to deploy an electronic authentication system that will work uni-
versally 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 Ser-
vices (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 state-
ments. 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.60 Under ACES, a user acquires a public key
certificate by interacting with one of a small number of selected, commer-
cial CAs. These CAs commit to certification policies and procedures con-
sistent 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 par-
ticipating government agencies. Federal agencies developing PKI-enabled
59see the Web site for a more detailed de-
scription of these 24 initiatives.
60The General services Administration is a federal management agency that sets policy
in areas related to federal procurement, real estate, and information resources.
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
171
applications are encouraged to take advantage of the Certificate Authen-
tication Module (CAM) a GSA-supplied and Mitretek-developed soft-
ware 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 con-
tacting 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 con-
sulting with other government records. This procedure needs to be re-
peated 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, be-
cause 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 gov-
ernment pays the CA for issuing an ACES certificate. Instead, every time
72
WHO GOES THERE?
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 invest-
ments 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 ex-
ceed 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 per-
forming 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 docu-
ments. 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
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
173
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 in-
cludes instructions for how to file using a Touch-Tone phone and a cus-
tomer 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 authenti-
cate 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 pre-
pared by tax preparers such as commercial services, certified public ac-
countants, and enrolled agents. Tax preparers do an even larger percent-
age of the returns prepared for e-file, a program that emerged out of a
partnership between the IRS and HER 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
74
WHO GOES THERE?
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 taxpay-
ers 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, taxpayers 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
taxpayers 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 taxpayers, the IRS is able to authenticate the trans-
action 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 re-
fund fraud. The IRS refers to the need for "revenue protection.''61 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 taxpayers
providing information from the previous year's tax return like Adjusted
Gross Income (AGI) so the IRS can validate claimed identity of the tax-
payer beyond name, address, and taxpayer identification number.
61Given 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.
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
The Social Security Administration and PEBES
175
One of the more infamous cases of privacy involving authentication
colliding with e-government capabilities comes from the SSA's Online
PEBES initiative.62 In 1997, the SSA had to bring down its otherwise-
successful Web-based capability allowing individuals to request and ulti-
mately 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 pro-
vided partial electronic service, taking the request electronically but re-
verting 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 au-
thentication 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.
62Zachary 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.
76
WHO GOES THERE?
The fully interactive PEBES was up for approximately 1 month before
the press depicted the offering as "social insecurity." The concern ex-
pressed by the press and by several senators who wrote to the commis-
sioner 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 ax-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.63
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 un-
likely 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 mo-
tor vehicles (DMVs). The committee's first report, IDs Not That Easy,64
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 consti-
tute 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
63For SSA's own analysis of PEBES, see "Privacy and Customer Service in the Electronic
Age: Report to Our Customers," available online at
AUTHENTICATION, PRIVACY, AND THE ROLES OF GOVERNMENT
177
Motor Vehicle Administrators is in the process of developing and propos-
ing standards to do that.65 They include provisions for the use of biomet-
rics to tie a driver to his or her license; some states already require finger-
prints. 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 nation-
wide identity system. They are widely accepted for transac-
tions 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 iden-
tify 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 li-
cense 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 govern-
ment, owing to its unique role and requirements. This report emphasizes
the need to avoid authentication or identification when mere authoriza-
65More information is available online at .
78
WHO GOES THERE?
lion 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 cer-
tain forms does not need to be verified before the forms are made avail-
able. The same holds true for many public records.)
Finding 6.7: Preserving the ability of citizens to interact anony-
mously with other citizens, with business, and with the govern-
ment is important because it avoids the unnecessary accumula-
tion 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) infor-
mation 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 au-
thentication system should be well articulated.