[Federal Register Volume 68, Number 133 (Friday, July 11, 2003)]
[Notices]
[Pages 41370-41374]
From the Federal Register Online via the Government Publishing Office [www.gpo.gov]
[FR Doc No: 03-17634]



[[Page 41370]]

=======================================================================
-----------------------------------------------------------------------

GENERAL SERVICES ADMINISTRATION

[2003-N02]


E-Authentication Policy for Federal Agencies; Request for 
Comments

AGENCY: Office of Electronic Government and Technology, GSA.

ACTION: Notice of policy and request for comments.

-----------------------------------------------------------------------

SUMMARY: The General Services Administration, in coordination with the 
Office of Management and Budget (OMB) request comments on the attached 
draft policy on E-Authentication for Federal Agencies. GSA has 
coordinated this draft policy with OMB and will work closely with OMB 
in reviewing comments and issuing the final policy. In this draft 
policy, GSA is requiring that agencies implement this E-Authentication 
Policy, which establishes four assurance levels to create a 
Governmentwide standard framework for determining what is required to 
access a particular Government transaction online.

DATES: To ensure consideration of comments, comments must be in writing 
and received by GSA no later than August 11, 2003.

ADDRESSES: Comments on this notice should be addressed to Ms. Von 
Harrison, General Services Administration; Office of Electronic 
Government and Technology (MEI), Washington, DC 20405. You are 
encouraged to submit these comments by facsimile to (202) 501-6455, or 
by electronic mail to [email protected].

FOR FURTHER INFORMATION CONTACT: Ms. Von Harrison, General Services 
Administration, Office of Electronic Government and Technology (MEI), 
Washington, DC 20405; or by phone at (202) 273-0721.

SUPPLEMENTARY INFORMATION: As required by the Government Paperwork 
Elimination Act of 1998 (Public Law 105-277), most transactions 
currently accomplished by filing a Government paper form will be 
converted to an electronic format. These transactions will require some 
type of identity verification or authentication before taking place. It 
is also important that these electronic transactions incorporate the 
appropriate level of security. This attached GSA policy guidance 
provides agencies with a policy for the use of electronic 
authentication (or e-authentication) in electronic transactions. As the 
Federal Government works to expand the use of information technology 
and e-government, trust in electronic transactions is especially 
critical.
    This memorandum establishes a four level approach for 
authentication to ensure trustworthy electronic transactions and to 
fulfill Federal privacy and information security requirements. These 
four levels reflect an increasing degree of confidence in the identity 
presented and represent a range of authentication technologies. This 
guidance will promote for the public--
    [sbull] Use of a standard set of criteria for assessing e-
government transactions authentication requirements;
    [sbull] Consistent terminology when discussing authentication and 
levels of assurance;
    [sbull] Secure, easy-to-use, and consistent method for managing 
identity in electronic transactions with the Government;
    [sbull] Burden reduction in Government services and Government 
filings;
    [sbull] Reuse of credentials for access to multiple Government 
services;
    [sbull] Clearly understood criteria for access to particular 
Government services; and
    [sbull] Protection against fraud in online transactions with the 
Government.
    Having a consistent e-authentication process and policy guidance 
will enable Federal Agencies to--
    [sbull] Reduce authentication system development and acquisition 
costs, and reallocate labor resources used to develop such systems;
    [sbull] Reduce the burden on the public in complying with repeated, 
duplicate or inconsistent processes of identity proofing;
    [sbull] Make consistent authentication decisions;
    [sbull] Promote public trust in the use of online service delivery;
    [sbull] Use existing and future e-authentication processes, within 
their organizations or those that are available Governmentwide; and
    [sbull] Reduce the number and type of electronic credentials that 
Federal employees, citizens, and businesses need to conduct business 
electronically with the Government.
    This guidance updates the Procedures and Guidance for Implementing 
the Government Paperwork Elimination Act (GPEA) issued by the Office of 
Management and Budget (OMB), which requires agencies to provide the 
option for electronic filing and electronic signature capabilities for 
Government activities and services unless it is not practicable to do 
so by October 2003. The GPEA implementation guidance (found at: http://www.whitehouse.gov/omb/memoranda/m00-10.html, April 25, 2000), provided 
agencies with guidance on the risk factors agencies should consider in 
planning and implementing electronic transactions. This e-
authentication policy updates the GPEA guidance to take in account 
current e-authentication practices, including the impacts of the E-
Authentication E-Government Initiative and recent National Institute of 
Standards and Technology (NIST) standards. NIST will be issuing 
companion technical guidance on this issue.
    This guidance reflects substantial work of the E-Authentication 
Initiative and the Federal CIO Council in FY 2003. Accordingly, CIOs 
are responsible for assuring all agencies or cross agency teams that 
implemented electronic authentication solutions or are planning to use 
shared authentication services are applying this policy.
    All existing transactions/systems which require authentication of 
their users must complete an e-authentication risk assessment and be 
categorized into one of the described assurance levels by September 15, 
2005. Agencies should complete the e-authentication risk assessment 
process in the following order:
    [sbull] The E-Government Initiatives (who have already started the 
process described in this guidance) must be completed by October 1, 
2003.
    [sbull] Systems classified as ``major'' should be completed by 
September 15, 2004.
    [sbull] New authentication solutions should begin to be categorized 
within 90 days of the completion of the final E-Authentication 
Technical Guidance.
    The results of the authentication risk assessment must be made 
publicly available through the agency Web site, the Federal Register, 
or other means (e.g., upon request). As part of the E-Authentication 
Initiative, E-Authentication will post the results of the assessments 
at a central location to allow for public access. In addition, the 
Business Compliance One Stop Initiative will be working with agencies' 
applications that concern small businesses. Agencies will be asked to 
report on their process as part of the requirements of Section 203 of 
the E-Government Act in the annual E-Government Act report due annually 
on September 15th beginning in 2004. Your cooperation and comments are 
appreciated.


[[Page 41371]]


    Dated: July 8, 2003.
G. Martin Wagner,
Associate Administrator for Governmentwide Policy.

Draft E--Authentication Policy for Federal Agencies

Section 1: Introduction
Section 2: Assurance Levels
Section 3: Determining Assurance for Credential Service Providers
Section 4: Implementing an Authentication Process
Section 5: Effective Dates of Guidance

1. Introduction

1.1. Summary

    [sbull] This guidance should be applied to all Federal 
electronic transactions requiring authentication, except those that 
are national security systems as defined in 44 U.S.C. 3542(b)(2).
    [sbull] This guidance does not stipulate which technology 
solutions should be implemented for each assurance level. The 
Department of Commerce's National Institute for Standards and 
Technology (NIST) is developing complementary e-authentication 
technical guidance that will be used by agencies to determine 
appropriate technology solutions, based on the process described in 
this guidance.
    [sbull] Agencies are required to review existing and categorize 
new electronic transactions to ensure that these transactions comply 
with this guidance.
    [sbull] As detailed in Section 9c of OMB's GPEA guidance, 
agencies should continue to minimize the likelihood of denial or 
repudiation of the information individuals transmit electronically. 
As an element of assessing the risks that are relevant to the 
required assurance level, agencies must consider how they plan to 
minimize the likelihood of repudiation by ensuring the user's 
approval of the information transmitted in electronic transactions. 
General guidance on minimizing the likelihood of repudiation is 
included in Section 8c of the OMB Procedures and Guidance on 
Implementing GPEA.
    [sbull] This guidance does not directly apply to authorization. 
Authentication focuses on establishing a person's identity, based on 
the reliability of the credential he or she offers; while 
authorization focuses on what actions that identity, at that level 
of assurance, is permitted to do. Decisions concerning authorization 
are and should remain the purview of the electronic business process 
owner.
    [sbull] Authentication is an inherent part of an electronic 
signature; however this guidance does not cover ``intent to sign,'' 
or when an agency uses authentication credentials as an electronic 
signature. For more information on electronic signatures, please 
consult OMB's guidance on implementing GPEA and the Electronic 
Signatures in Global and National Commerce Act (found at: http://www.whitehouse.gov/omb/memoranda/m00-15.html, September 25, 2000).
    [sbull] Agencies should implement an e-authentication process 
using the following steps, described in Section 2.2: (1) Conduct a 
risk assessment as explained in Part II of the GPEA guidance and 
Section 2 of this guidance, (2) match identified risks with 
assurance levels, and (3) determine implementation technology based 
on the e-authentication technical guidance.
    [sbull] Each step of the authentication process--from identity 
proofing, to issuance of a credential, to technical and 
administrative management and use of the credential by an 
application, and ultimately to record keeping and auditing--
influences whether the process conforms to the desired assurance 
level. There are many layers of risk related to authentication. This 
guidance document is intended to assist agencies in identifying and 
analyzing risks associated specifically with the improper 
authentication of users of electronic transactions. These risks are 
highly dependent on the type of application and transactions 
offered.
    [sbull] This document does not address risks that are associated 
with the improper management of authentication controls or 
processes, or risks to the underlying authentication technical 
architecture or infrastructure. This document does not confer, and 
may not be used to support, any right on behalf of any person or 
entity against the United States or its agencies or officials.
    [sbull] This guidance does not refer to the authentication of 
systems or between services (for example, security socket layer 
(SSL) authentication). Instead, it is focusing on the attribute or 
identity authentication of individuals who are authenticated for 
Government services online.

1.2. Overview

    This document provides agencies with guidance on electronic 
identity and attribute authentication (or e-authentication). E-
authentication is the process of establishing confidence in both 
identities and attributes after being electronically presented to an 
information system. Individual authentication is the process of 
establishing an understood level of confidence that an identifier 
refers to a specific individual. Attribute authentication is the 
process of establishing an understood level of confidence that an 
attribute applies to a specific individual. The process of e-
authenticating an individual may involve establishing the 
individual's unique identity (identity authentication) or 
establishing that the individual is a member of a group (such as a 
military veteran or U.S. citizen) (attribute authentication). For a 
complete list of definitions, refer to the Report of the National 
Research Council ``Who Goes There? Authentication Through the Lens 
of Privacy'' (found at: http://www.nap.edu/books/0309088968/html/, 
March 31, 2003).
    E-authentication is the first step in the related process of 
deciding what an individual ought to be allowed to do, called 
``authorization.'' Authentication focuses on establishing a person's 
identity, based on the reliability of the credential he or she 
offers; while authorization focuses on what actions that identity is 
permitted to do.
    Agencies providing the e-government services need to determine 
how certain they need to be in the identity of an individual and 
identify the risks inherent in a particular transaction. This 
guidance will provide the framework for the identified risks to be 
mapped to the desired assurance level that the authentication 
technology selected must satisfy.
    As described in OMB Circular A-130, Management of Federal 
Information Resources, agencies must prepare and update a strategy 
that identifies and mitigates risks associated with each information 
system; Section 5 of the GPEA guidance detailed the risk factors 
agencies should consider in planning and implementing electronic 
transactions. This new e-authentication guidance expands on Section 
5 by--
    [sbull] Instructing agencies how to implement an e-
authentication process by outlining a process for assessing risk, 
and determining the requisite level of identity assurance; and
    [sbull] Describing four discrete (and increasing) levels of 
identity assurance.

2. Assurance Levels

2.1. Description of Assurance Levels

    For the purposes of e-government transactions, this guidance 
describes four assurance levels for authentication. In this context, 
assurance is defined as how much confidence the relying party has 
that the electronic identity credential presented is done so by the 
person whose identity is asserted by the credential. These levels 
are each appropriate for different classes of electronic 
transactions. In general, informal or lower value transactions will 
require less stringent assurance levels. Higher value or legally 
significant transactions will require more stringent assurance 
levels.

2.2. How To Determine an Assurance Level

    Step 1: Agencies should conduct a systematic risk assessment of 
the transaction. The risk assessment will determine the required 
assurance level and will measure the relative severity of the 
potential harm to the agency or user of the e-government application 
and other transaction participants in the event of an improperly 
validated or unauthorized authentication. Each of the 4 levels 
described in Section 2.4 contains a profile of consequential risks. 
The more severe the likely consequences, the more confidence 
required in the asserted electronic identity in order to engage in a 
transaction, and, therefore, the higher the assurance level 
required. The definition of each assurance level is directly 
correlated to the degree of confidence or certainty that the agency 
must have in the identity of the user. Assurance levels are the 
vital link between the risk assessments of applications and the 
selection of authentication solutions.
    Agencies should consider a wide range of possible scenarios in 
seeking to determine what risks are associated with their business 
process. It is better to be over inclusive than under inclusive in 
conducting this analysis. Risk analysis is to some extent a creative 
process, in which agencies must consider harms that might result 
from, among other causes, technical failures, malignant third 
parties, public misunderstandings, and human error.
    Step 2: Match identified risks with assurance levels. The 
results of the risk assessment should be summarized, and then

[[Page 41372]]

be directly compared to these profiles. The closest match to one of 
the level profiles will determine the assurance level. In 
determining the required assurance level, an agency should initially 
identify risks inherent in the transactional process without 
considering the particular technologies used to implement 
authentication for that transaction. For example if during a medical 
procedure, the misuse of a user's electronic identity/credentials 
might result in risk to the user's personal safety, then, following 
this guidance, the agency would assign a level 4 assurance to this 
transaction, even if potential financial loss or other consequences 
are minimal. In making this determination, business process owners 
should seek to use the minimum assurance level that meets their risk 
requirements.
    Step 3: Determine implementation technology based on the e-
authentication technical guidance. After the assurance level has 
been determined, the agency should refer to the e-authentication 
technical guidance for the process requirements corresponding to 
that level. After the technical solution is chosen, a final 
validation should be conducted to confirm that the required 
assurance level of the end-to-end user to agency process has been 
operationally achieved. Note that authorization determines whether 
or not the authenticated has rights to complete the transaction.
    Note that some technology solutions may create or compound 
particular risks. Thus, after selecting a specific solution, the 
agency should validate that the performance of the authentication 
process itself actually meets the identity assurance requirements 
for the transaction as part of required security procedures (e.g., 
certification and accreditation).

2.3. Assurance Levels: Descriptions and Examples

    This section describes the four assurance levels. The levels 
represent ranges of confidence in an electronic identity presented 
to an agency by means of a credential. The levels are numbered from 
1 to 4, with 1 being minimal assurance and 4 being the highest level 
of identity assurance.
    For each level, there is a description and examples. The 
description and examples will assist the agency in identifying the 
appropriate level of assurance required to authorize a transaction. 
The key part of each description is a risk profile. This is a 
description of certain consequential risks that may ensue to 
participants in a transaction when there is an authentication error.

Level 1--Minimal Assurance

Description

    At level 1, little or no assurance is placed in the asserted 
electronic identity of the transacting party. In particular, an 
authentication error of a user's identity at level 1 might result in 
at most--
    [sbull] Minimal inconvenience to any party; and
    [sbull] No financial loss to any party; and
    [sbull] Minimal distress being caused to any party; and
    [sbull] Minimal damage to any party's standing or reputation; 
and
    [sbull] No risk of harm to agency programs or other public 
interests; and
    [sbull] No risk of civil or criminal violations; and
    [sbull] No release of personal, U.S. government sensitive, or 
commercially sensitive data to unauthorized parties; and
    [sbull] No risk to any party's personal safety.

Examples

    Examples of transactions that might merit level 1 authentication 
include--
    [sbull] A user presents a self registered user ID or password to 
the United States Department of Education web page, which allows 
customization of a Web site to create a ``My.ED.gov'' page. There 
are some possible risks associated with this situation; for example, 
a third party who gained unauthorized access to such a user ID and 
password might be able to draw inferences about the user's business 
interests or plans or the user's personal situation based on the 
types of information in which the user has an interest. Unless the 
website is subject to a high degree of customization, however, these 
risks are probably very minimal.
    [sbull] A user participates in an online discussion on the 
whitehouse.gov website. Assuming that the forum is not one that 
addresses sensitive or private information, there are no obvious 
risks associated with this situation.

Level 2--Low Assurance

Description

    Level 2 is appropriate for transactions in which it is 
sufficient that, on the balance of probabilities, there is 
confidence in the asserted electronic identity of the transacting 
party. In particular, an authentication error of a user's identity 
at level 2 might result in--
    [sbull] Minor inconvenience to any party; or
    [sbull] Minor financial loss to any party; or
    [sbull] Minor damage to any party's standing or reputation; or
    [sbull] Minor distress being caused to any party; or
    [sbull] Minor risk of harm to agency programs or other public 
interests; or
    [sbull] A risk of civil or criminal violations of a nature that 
would not ordinarily be subject to agency enforcement efforts; or
    [sbull] A minor release of personal, or commercially sensitive 
data to unauthorized parties; and
    [sbull] No release of U.S. government sensitive data to 
unauthorized parties; and
    [sbull] No risk to any party's personal safety.

Examples

    Examples of transactions that might merit level 2 assurance 
include--
    [sbull] A user engages in online learning on the Gov Online 
Learning Center at golearn.gov. There is a need for authentication 
such that the user is recognized by the training service and be 
connected to the appropriate place in the course or given relevant 
assignment grades, when training affects compensation or promotion. 
The only risk associated with this transaction is that a third party 
will gain access to grading information, causing harm to the privacy 
interests or reputation of the student. If the agency determines, in 
the context of the particular program, that any such harm will be 
minor, the transaction is level 2.
    [sbull] A user accesses their Social Security retirement account 
information online.

Level 3--Substantial Assurance

Description

    Level 3 is appropriate for transactions that are official in 
nature, and for which there is a need for high confidence in the 
asserted electronic identity of the transacting party. In 
particular, an authentication error of a user's identity at level 3 
might result in--
    [sbull] Significant inconvenience to any party; or
    [sbull] Significant financial loss to any party; or
    [sbull] Significant damage to any party's standing or 
reputation; or
    [sbull] Significant distress being caused to any party; or
    [sbull] Significant harm to agency programs or other public 
interests; or
    [sbull] A risk of civil or criminal violations that may be 
subject to agency enforcement efforts; or
    [sbull] A significant release of personal, U.S. government 
sensitive, or commercially sensitive data to unauthorized parties; 
and
    [sbull] No risk to any party's personal safety.

Examples

    Examples of transactions that might merit level 3 assurance 
include:
    [sbull] A patent attorney company reports and updates data on-
line with the Patent and Trademark Office that would be of great 
value as competitive intelligence.
    [sbull] A major contractor or supplier maintains an account with 
a General Services Administration Contracting Officer for a large 
government procurement involving significant government 
expenditures.
    [sbull] A First Responder accesses a disaster management 
reporting website to report an incident and to share incident 
operational information, and to coordinate incident response 
activities.

Level 4--High Assurance

Description

    Level 4 is appropriate for transactions that are official in 
nature for which there is a need for very high confidence in the 
asserted electronic identity of the transacting party. In 
particular, an authentication error of a user's identity at level 4 
might result in--
    [sbull] Considerable inconvenience to any party; or
    [sbull] Considerable financial loss to any party; or
    [sbull] Considerable damage to any party's standing or 
reputation; or
    [sbull] Considerable distress being caused to any party; or
    [sbull] Considerable harm to agency programs or other public 
interests; or
    [sbull] A risk of civil or criminal violations that are of 
special importance to the agency enforcement program; or
    [sbull] A damaging release of extensive personal, U.S. 
government sensitive, or commercially sensitive data to third 
parties; or
    [sbull] A risk to any party's personal safety.

Examples

    Examples of transactions that may require level 4 assurance 
include--

[[Page 41373]]

    [sbull] A State or local law enforcement official accesses a law 
enforcement database containing information about the criminal 
records of individuals. Unauthorized access would violate the legal 
privacy rights of individuals or compromise investigations.
    [sbull] A VA pharmacist dispenses a controlled drug. He/She 
would need full assurance that a qualified doctor had signed the 
prescription. In this case, the pharmacist's actions on the 
transaction carries criminal liability that the prescription was the 
correct drug(s), in the correct quantity, and that the prescription 
was validated before filling the prescription.

2.4. Additional Considerations

    Each step of the authentication process--from identity proofing, 
to issuance of a credential, to management and use of the credential 
in a well-managed secure application, and ultimately to record 
keeping and auditing--influences whether the process conforms to the 
desired assurance level. The level of assurance achieved by each 
step of the process needs to be considered. The step that provides 
the lowest level of assurance may often determine the assurance 
level for the entire authentication process. Ideally each step in 
the authentication process should be consistent in its strength and 
robustness. A strong identity proofing process, combined with a 
strong credential and a robust management practice (including a 
strong archive and audit process) will contribute to the highest 
level assurance of identity. However, the best authentication 
process needs to be supported by well-engineered and tested user and 
agency software applications.
    In making the risk assessment, the business process owner must 
consider all the direct and indirect consequences as presented in 
the definitions of the levels. Since each assurance level uses the 
terms ``minimal'', ``minor'', ``significant'', or ``considerable'', 
the business process owner will need to consider the terms in the 
context of the parties likely to be affected and their typical 
views. While it is realized that these terms are subjective, it is 
expected that these will be solidified through implementation and 
practice. For example, risk assessments have already been conducted 
on the E-Government Initiatives to determine their appropriate 
assurance levels.
    As stated in OMB's GPEA guidance, properly implemented 
technologies can offer degrees of confidence in authenticating 
identity that are greater than a handwritten signature can offer. 
However, electronic transactions may in some circumstances affect 
the risk of criminal and civil violations, increase the harms 
associated with such violations, and complicate redressing such 
violations. Legal and law enforcement issues are discussed in the 
Department of Justice's Guide for Federal Agencies on Implementing 
Electronic Processes (found at http://www.cybercrime.gov/ecommerce.html#GFA, November 2000). Agencies should consider these 
issues in assigning transactions to particular assurance levels.
    Violations of the law can present significant policy issues for 
an agency. The risk assessment process should consider the potential 
effects of illegal activities or other process failures in light of 
the agency's enforcement priorities, the agency's programmatic 
interests, and such broader public interests as national security, 
the environment, and the proper functioning of markets. Some of 
these harms are specifically described in each level (such as 
financial loss or release of personal information); others will 
depend on a particular agency's programmatic interests.
    The risk analysis reflects this issue by referring to risks of 
criminal or civil violations and harm to agency programs or the 
public interest. In assessing this risk and designing a process, 
agencies should take into account not just the effects of a single 
violation or other act, but the possibility of a pattern of actions 
that might affect agency programs. For instance, if sensitive 
information could be obtained from an agency website, the agency 
should consider the effects of a possible pattern of such activity, 
not just a single action, in assessing risk levels. (Note that 
unauthorized access to an agency website is itself a criminal 
offense, see, e.g., 18 U.S.C. 1029, 1030. Agencies should consider 
the effects and risks associated with such unauthorized access, 
rather than focusing on the unauthorized access itself, in assessing 
such risks.)

3. Determining Assurance for Credential Service Providers

    Credential Service Providers (CSPs) are organizations, both 
governmental and non-governmental, that issue and in some cases may 
maintain electronic credentials. CSPs can handle several of the 
steps in the e-authentication process. Because the CSP's issuance 
and maintenance policy influences the trustworthiness of an e-
authentication process, CSPs will also need to be assessed to 
determine the e-authentication level to which their credentials 
pertain. For example, if a CSP follows all process/technology 
requirements for authentication level 3, a user may use a credential 
provided by the CSP to authenticate himself for a transaction 
requiring authentication levels 1, 2, or 3. Additional information 
on CSPs will be included in both the E-Authentication technical 
guidance and in separate guidance issued by the E-Authentication E-
Government Initiative.

4. Implementing an Authentication Process

4.1. Overview of the E-Authentication Process

    When determining e-authentication needs, agencies must consider 
the entire e-authentication process. An agency cannot simply 
determine the level of credential that will be required to validate 
a user's identity without also determining how that credential will 
be processed by the agency business applications. They must 
determine the requirements for each step in the e-authentication/
authorization process. This process includes the following steps:
    [sbull] Initial enrollment.
    [sbull] Repeat visits.
    [sbull] Verification of identity.
    [sbull] Transaction management.
    [sbull] Long term records management.
    [sbull] Periodic tests of the system.
    [sbull] Suspension, revocation, reissue.
    [sbull] Audit.
    Each of these steps will be explained in more detail in the e-
authentication technical guidance. Responsibility for these steps 
lies with the individual business process owners or designated 
agency or cross agency authority.

4.2. Use of Anonymous Credentials

    Anonymous credentials may be appropriate when it is not 
necessary that authentication be associated with a known personal 
identity (as opposed to identity authentication). To protect 
privacy, it is important to balance the need to know who is 
communicating with Government with a citizen's right to privacy. 
This includes ensuring that information is used only in the manner 
in which individuals have been assured it will be used. In some 
cases, it may be desirable to preserve the anonymity of individuals 
and it may be sufficient for the purposes of an application to 
authenticate that--
    [sbull] The user is a member of a group; and/or
    [sbull] The user is the same individual who supplied or created 
information in the first place; and/or
    [sbull] A particular user is entitled to use a particular 
pseudonym.
    These anonymous credentials will have limited application. In 
some cases, individuals would have an anonymous as well as a non-
anonymous credential. Anonymous credentials can be used up until 
level 3.

4.3. Information Sharing and the Privacy Act

    When developing authentication processes, agencies must consider 
the requirements for managing security in the collection and storage 
of information associated with the process of validating a user's 
identity. As required by the E-Government Act of 2002 (Public Law 
107-347), section 208, 44 U.S.C. Sec.  3604, agencies are required 
to conduct privacy impact assessments for electronic information 
systems and collections, which includes when authentication 
technology is newly applied to an electronic information system.
    The following information is captured in most e-authentication 
processes:
    [sbull] Information regarding the individuals/ businesses/
governments using the E-Gov service.
    [sbull] Electronic user credentials (i.e., some combination of 
public key certificates, user identifiers, passwords, and Personal 
Identification Numbers).
    [sbull] Transaction information associated with user 
authentication, including credential validation method.
    [sbull] Audit Log/Security information.
    Some of this information includes personal information as 
defined by the Privacy Act and, systems that use the information are 
considered systems of records that must meet all requirements of the 
Privacy Act and the E-Government Act.
    Data collected and stored during the authentication process 
should only be accessible routinely to systems administrators and to 
auditors. As required by the Privacy Act, access to the system of

[[Page 41374]]

records must be provided to registered users to allow them to see 
and/or change personal information about them maintained in the 
system of records. Information from the system of records should not 
be shared routinely outside of legitimate needs as permitted or 
required by law for the administration and control of the 
authentication process.
    In order to authenticate a user, it may be necessary for an 
agency providing an E-Gov service to obtain additional information 
about that user through the CSP that issued the user his/her 
credential. In such a case, the CSP must ask the user for permission 
and be granted that permission by the user to provide the specified 
information to the e-gov service provider. Disclosure of the 
additional information by the CSP to the e-gov application or 
service may also be established prior to the time of the 
transaction, if it is outlined in the terms of the relationship 
between the user and the CSP.

4.4. Cost Considerations

    In most cases, higher levels of assurance require more costly 
credentials; however minimizing the number of credentials can create 
cost savings. Section 3 of the GPEA guidance provides additional 
information on assessing risks, costs, and benefits. In-person 
proofing is most likely more expensive. The e-authentication 
technical guidance will provide alternatives for addressing some of 
the authentication levels that may help agencies to better manage 
the costs of authentication.

4.5. Relationship to Other Guidance

4.5.1. Federal Bridge Certification Authority

    Federal Bridge levels will be mapped to the assurance levels 
described in this document. Since these assurance levels take into 
account a wide range of authentication solutions, the levels 
described in this guidance differ from the levels established by the 
Federal Bridge Certification Authority (FBCA) Certificate Policy. 
For example, levels 1 and 2 in this e-authentication policy are 
primarily reserved for non-cryptographic authentication solutions 
not covered by the FBCA. However, it is likely that some public key 
infrastructure (PKI) solutions and the FBCA Rudimentary Certificate 
Policy will map to level 1 or level 2. The FBCA Basic Certificate 
Policies and the FBCA Medium Certificate Policies will fall in level 
3, while FBCA High Certificate Policy will fall into level 4.

4.5.2. Federal Information Processing Standards Publication 199

    While this E-Authentication Guidance addresses the consequential 
risk in making an authentication error, NIST is in the process of 
developing much broader risk levels for Federal information and 
Information Systems. NIST is in the process of developing a Federal 
Information Processing Standards Publication (FIPS) 199, ``Standards 
for Security Categorization of Federal Information and Information 
Systems'' promulgated under the E-Government Act of 2002 (Public Law 
107-347). The standards establish three levels of risk (low, 
moderate, and high) for each of the stated security objectives 
(confidentiality, integrity, and availability) relevant to securing 
Federal information and information systems.
    It is expected that these levels established in FIPS 199 will 
map to the levels in the e-authentication guidance. When an 
authentication error might cause a loss of confidentiality, 
integrity or availability, then--
    [sbull] If the risk as defined in FIPS 199 is low, 
authentication assurance levels 1 through 4 are sufficient;
    [sbull] If the risk as defined in FIPS 199 is moderate, 
authentication assurance level 3 or 4 should be used; and
    [sbull] If the risk as defined in FIPS 199 is high, 
authentication assurance level 4 should be used.

5. Effective Dates of This Guidance

    The Effective Dates for this guidance is 30 days after issuance 
as final policy. Additional information can be found in the 
supplemental information above.

[FR Doc. 03-17634 Filed 7-10-03; 8:45 am]
BILLING CODE 6820-WY-P