[Federal Register: July 11, 2003 (Volume 68, Number 133)]
[Notices]
[Page 41370-41374]
From the Federal Register Online via GPO Access [wais.access.gpo.gov]
[DOCID:fr11jy03-63]
[[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 egov.taskforce@gsa.gov.
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]