05-15515. Notice; Establishment of E-Authentication Service Component

AGENCY:

Office of Governmentwide Policy, General Services Administration, GSA.

ACTION:

Notice and request for comments.

SUMMARY:

In accordance with the Privacy Act of 1974, as amended, the General Services Administration (GSA) proposes to establish the E-Authentication Federation, or “Service Component.” The E-Authentication Service Component is a common infrastructure for electronically authenticating the identity of users of Federal E-Government services Governmentwide. Using a common network, this infrastructure links identity suppliers (termed Credential Service Providers or CSPs) and identity consumers (termed Agency Applications or AAs) enabling participating CSPs and AAs to communicate in a standardized way. The E-Authentication Service Component does not create or maintain any new Federal System of Records, but does provide for the authorized exchange of information among systems of records that have been or will be established to support Federal E-Government programs and services.

DATES:

Submit comments on or before: September 6, 2005.

FOR FURTHER INFORMATION CONTACT:

David Temoshok, Director, Identity Policy and Practices, Office of Governmentwide Policy at telephone [phone] or via e-mail to [e-mail].

ADDRESSES:

Comments on this Notice should be addressed to David Temoshok, Director for Identity Policy and Practices, Office of Governmentwide Policy. Comments should be mailed to the attention of Ms. Barbara J. Vitko, GSA 1800 F Street NW, Room 2239, Office of Technology Strategy, Washington, DC, 20405-0002. Comments may be submitted by facsimile to [phone].

SUPPLEMENTARY INFORMATION:

As part of the President's Management Agenda, the E-Authentication Service Component is established to enable trust and confidence in E-Government transactions through the establishment of an integrated policy and technical infrastructure for electronic authentication. Through this initiative, citizens, businesses, and governmental entities will have simpler access to multiple agency applications through the re-use of credentials and established identities. GSA is making the E-Authentication Service Component (ASC) available to Federal E-Government applications through the Federal Enterprise Architecture. In this way, Federal agencies can use the common policy and technical infrastructure of the ASC without the cost and burden of re-creating the infrastructure individually.

GSA has been designated by the Office of Management and Budget (OMB) as the lead agency for the development, implementation and operation of the Federal electronic authentication infrastructure. GSA has established a Program Management Office (PMO) in the Federal Technology Service for the operation of the ASC. The GSA Office of Governmentwide Policy provides policy support for the initiative.

After careful analyses and proofs-of-concept, GSA determined that the most viable means to implement a common E-Authentication infrastructure was through a decentralized approach. The E-Authentication Service Component leverages credentials from multiple credential providers through certifications, guidelines, standards and policies. The E-Authentication Service Component accommodates assertion-based authentication (i.e., authentication of PIN and Password credentials) and certificate-based authentication (i.e., Public Key Infrastructure (PKI) digital certificates, and other forms of strong authentication) within the same environment. Over time, the E-Authentication Service Component will support multiple protocols and communication schemes and, therefore, is not built around a single scheme or commercial product. The E-Authentication Service Component currently uses the industry standard of SAML 1.0.

The E-Authentication Service Component is aligned with OMB Policy Memorandum M-04-04, E-Authentication Guidance for Federal Agencies (http://www.whitehouse.gov/​omb/​memoranda/​fy04/​m04-04.pdf), which provides policy guidance for identity authentication and establishes four levels of authentication assurance. It is also aligned with National Institute for Standards and Technology (NIST) Special Publication 800-63, Recommendation for Electronic Authentication (http://csrc.nist.gov/​publications/​nistpubs/​800-63/​SP800-63v6_​3_​3.pdf). This document accompanies and supports OMB M-04-04 and provides technical and procedural requirements for authentication systems which correlate to the four defined authentication assurance levels defined in OMB M-04-04. The E-Authentication Service Component provides the infrastructure for Federal agencies to implement the policies and recommendations of OMB M-04-04 and NIST SP 800-63. These documents as well as other technical, policy, and informational documents and materials can be accessed at the website: http://www.cio.gov/​eauthentication.

Following are the key requirements and design goals established for the E-Authentication initiative.

Key Requirements:

• Leverage credentials: A credential from any approved credential service should be usable at any application of equal or lower assurance level. Agency applications must be able to leverage existing credentials rather than establish new identity management systems.
• Single Sign-on: Once a user has authenticated they must be able to move among applications with equivalent assurance levels without re-authenticating. For privacy considerations, the end user is required to take an explicit action to opt into single sign-on for that browser session.
• Privacy: There must be no central repository of personal information about end users and no centralized database. Credentialing must be federated among multiple providers. End users can choose to federate their identity information as they determine appropriate.
• Security controls: The architecture must provide for explicit control over which applications and credential services can join and participate in the E-Authentication Federation.

Design Goals:

• Standards: The architecture should rely on existing industry standards.
• COTS: The architecture should employ multiple Commercial-off-the-Shelf (COTS) products that have demonstrated the capability to interoperate.
• Federation: Authentication should be federated among multiple credential providers.
• Durability: The architecture should be designed to allow for the evolution of technology, providing for easy migration as the industry and technology evolves.
• Flexibility: The architecture should not create undue reliance on any single standard, vendor, product, or integrator.

Based on these requirements and design goals, the technical approach for E-Authentication is to allow for multiple identity management schemes (e.g., identity proofing, credential technology, credential strength, credential management) within a single architecture. The framework includes a methodology and process for the evaluation and adoption of these schemes over time. The goal of the framework is to provide a lasting architectural model for E-Authentication that is not irrevocably bound to a single industry standard, vendor, or product.

The Federal E-Authentication Service Component establishes four levels of authentication assurance, defines risk management guidelines for associating a required level of authentication to applications, and provides a Credential Assessment Framework for evaluating authentication systems to determine whether they meet Federal standards for any of the four specified authentication levels. The initiative also provides a technical architecture that leverages federated identity through the use of Security Assertion Markup Language (SAML) 1.0, PKI (X509 v.3 certificates), and the Federal Bridge Certification Authority.

The E-Authentication Federation:

The E-Authentication Service Component is designed to ensure that government services delivered over the Internet are accessed by and delivered to the intended individual. The E-Authentication Service Component allows authorized participants to share responsibility for federating identity to mutual benefit. Together, the E-Authentication Service Component and the authorized participants of the service component represent the E-Authentication Federation. The participants of the E-Authentication Federation are:

• Agency Applications (AAs): E-Government applications that perform some business function online. If an E-Government application has multiple interfaces (e.g., administration and service application), each interface with distinct authentication requirements is considered a stand-alone AA. Agency Applications manage all business transactions and all end user authorization decisions. One of the principle goals of the E-Authentication initiative is to provide broad authentication services to AAs, making separate credentialing unnecessary.
• Credential Services Providers (CSPs): Commercial or government services which provide end users identity management services which include credentials that can be used at E-Authentication-enabled AAs. Credential Services Providers are authorized to participate in the E-Authentication Federation by the GSA E-Authentication Program Management Office (PMO). Authorized CSPs are presented to the public on the E-Authentication Federation Trust List. The Trust List of Authorized Credential Services is available at the E-Authentication website (http://www.cio.gov/​eauthentication/​TCSPlist.htm) and at the E-Authentication portal.
• E-Authentication Portal: A website that helps users locate the CSPs and AAs they need to complete their transactions. The portal is maintained and operated by the E-Authentication PMO.
• End Users: Any citizen, Government employee, contractor, business, or governmental entity that uses an AA. One of the principle goals of E-Authentication is to make the end user experience as simple as possible by improving the availability and ease of use of credentials.

Authentication Service Component Operations:

Within the framework of the E-Authentication Service Component, the end user interacts directly with AAs, CSPs, and the E-Authentication Portal. Typically the user starts at the portal in order to locate the appropriate AAs and CSPs which the end user intends to use. The end user can choose the AA that they wish to access and the CSP that they choose to validate their credential(s). In general, AAs are E-Government services that agencies provide end users; typically, the agencies maintain records on individuals' use of the services provided. Authentication of end users is required to allow authorization privileges in accordance with the rules of the AA. The E-Authentication Federation uses the term “activation process” to refer to the process of matching the authenticated end user to the correct individual in an AA records system.

The end user interacts directly with the CSP to obtain, manage, and validate their credentials. The CSP interacts directly with the AA in order to pass the end users' identity information. The identity information that is passed between the CSP and the AA is standardized for the E-Authentication Federation through the requirements of the E-Authentication Technical Interface Specifications. The ASC currently uses the OASIS standard Security Assertion Mark-up Language (SAML) 1.0 to express authentication identity assertions. Technical documents describing the E-Authentication architecture and the E-Authentication Interface Specifications for the SAML Artifact Profile can be found at http://www.cio.gov/​eauthentication/​TechSuite.htm. The Interface Specifications require the following information to be contained in the SAML assertion between the Credential Service Provider and an e-Government Agency Application which is the relying party to the identity assertion:

• Common Name: expressed as First Name, Middle Name, Last Name, suffix surname;
• User ID: provided by the CSP so that no two subscribers within a credential service can share the same User ID;
• Authentication Assurance Level: i.e., assurance level 1, 2, 3, or 4; and
• CSP: CSP is identified in the assertion.

Since the SAML assertion contains only common name and user ID of the end user for the selected CSP, most agencies have determined that a separate activation process is necessary to identify the specific individual as represented in the AA. This generally requires creating a separate query process to identify the end user to the AA. To facilitate the activation process and avoid requiring the end user to reenter the same identifying information multiple times, GSA is proposing to add the following attribute information to the SAML 1.0 Interface Specifications as optional information:

• Partial Social Security Number (SSN): the last four digits of the end users' SSN;
• Date of Birth (DOB): MM/DD/YYYY; and
• Physical Address: street address, city, state, and zip code.

The end user name, partial SSN, physical address and DOB are intended to allow the AA to identify the correct end user during the activation process, without necessarily requiring the AA to query the end user for any additional information. AAs will match the last four digits of the identity information in the SAML assertion against the information currently maintained in application records systems. The Interface Specification requires that CSPs which do not collect or maintain SSN, DOB, and/or physical address information to enter a null field for these attribute elements. The attribute information contained in the assertion is intended for the purposes of activation, and will not be provided to agencies that do not already have the authority to maintain this attribute information. AAs/records systems that do not collect or maintain the attribute fields of SSN, DOB, or physical address will not be passed that information in the SAML assertion from the CSPs. The E-Authentication AAs can also determine that they do not want to receive the additional attribute information of partial SSN, DOB and physical address and can opt out of receiving this information in the SAML assertions.

The E-Authentication Federation/Service Component does not involve any new collection of information from end users. If a Federal agency chooses to create or modify a records system to maintain information expressed in the SAML assertion, it must establish or amend a system of records (SOR) notice through publication in the Federal Register. Federal agencies that serve as CSPs or AAs may choose to maintain audit logs for browser-based access; such logs may include transaction data associated with the SAML assertion. Such audit logs are used to monitor browser access and are not considered systems of records requiring coverage under the Privacy Act.

Once the identity information is known to the AA, the user interacts directly with the AA for business transactions. While the E-Authentication Service Component addresses the need for common infrastructure for authenticating end users to applications, authorization privileges at the application are beyond the scope of the E-Authentication initiative. Authorization and related functionality such as access control and privilege management are left to the application owners.

Ensuring trust between the participating entities of the E-Authentication Federation (AAs, CSPs and End users) is core to the mission of the E-Authentication initiative. The E-Authentication Service Component provides:

• Policies and guidelines for Federal authentication;
• Credential assessments and authorizations;
• Technical architecture and documents, including Interface Specifications, for communications within the E-Authentication Federation Network;
• Interoperability testing of candidate products, schemes or protocols;
• Business rules for operating within the Federation; and
• Management and control of accepted federation schemes operating within the environment.

The E-Authentication Service Component technical approach has two different architectural techniques, assertion-based authentication and certificate-based authentication. PIN and Password authentications typically use assertion-based authentication, where users authenticate to the selected CSP, which in turn asserts their identity to the AA. Certificate-based authentication relies on X.509v3 digital certificates in a Public Key Infrastructure (PKI) for authentication, and can be used at any assurance level. PKI credentials offer considerable advantages for authentication. Certificates can be validated using only public information. Standards for PKI are also more mature than other authentication technologies and more widely used than the emerging standards for assertion-based authentication of PIN and password credentials. Nevertheless, the E-Authentication Service Component incorporates both assertion-based and certificate-based authentication to provide the broadest range of flexibility and choices to Federal agencies and end users.

System of Records Notice Requirements:

The purpose of the notice is to explain the E-Authentication Service Component, how it operates, and how participants, including end users, in the Federation relate. The E-Authentication Service Component portal merely routes the end user to the AA or CSP which the end user has chosen to access. The portal maintains no personally identifiable information about end users and therefore this notice proposes no new Privacy Act system of records.

However, Federal agency participants in the E-Authentication Service Component may maintain systems of records under the Privacy Act. Federal participants maintaining Privacy Act Systems of Records relating to identity authentication must develop appropriate systems of records notices with routine uses providing for the exchange of information through the Federation. As an initial matter, agencies must ensure they possess the appropriate authority to collect and maintain records in order to interface with the E-Authentication Federation. Additionally, agencies must publish Privacy Act Systems of Records notices in the Federal Register in accordance with guidance set out in OMB Circular A-130, Appendix 1. For further information contact, E-Authentication Service Component manager, Stephen Timchak, Director, E-Authentication Program Management Office, Suite 911, 2001 Crystal Drive, Arlington VA 22202. Mr. Timchak can be reached at 703-872-8604 or via email [e-mail].

Dated: August 1, 2005

June V. Huber,

Director, Office of Information Management.