FICAM TFS TEM on Identity Resolution Needs for Online Service Delivery

The FICAM Trust Framework Solutions (TFS) Program is convening public and private sector experts in identity proofing, identity resolution and privacy for an Identity Resolution Needs for Online Service Delivery Technical Exchange Meeting (TEM) on 5/1/14 from 9:00 AM - 5:00 PM EST in Washington, DC.

REGISTRATION

Save the 5/1/14 date! In-person attendance and early registration (due to limited space) are recommended.

Register Now!

Registration is now closed for this event!

Event Location: GSA, 1800 F St NW, Washington, DC 20405

In-person event logistics information will be provided to registered attendees. Remote attendance information will be made available to registered attendees who are not able to attend in-person.

Questions? Please contact the FICAM TFS Program at TFS.EAO@gsa.gov

BACKGROUND

Identity attributes that are used to uniquely distinguish between individuals (versus describing individuals) are referred to as identifiers. Identity resolution is the ability to resolve identity attributes to a unique individual (e.g. no other individual has the same set of attributes) within a particular context.

Within the context of enabling high value and sensitive online government services to citizens and businesses, the ability to uniquely resolve the identity of an individual is critical to delivering government benefits, entitlements and services.

As part of the recent update to FICAM TFS, we recognized the Agency need for standardized approaches to identity resolution in our Approval process for Credential Service Providers (CSPs) and Identity Managers (IMs).

The study done by the NASPO IDPV Project, "Establishment of Core Identity Attribute Sets & Supplemental Identity Attributes – Report of the IDPV Identity Resolution Project (February 17, 2014)" is currently being used as an industry based starting point for addressing this need. The study proposed 5 equivalent attribute bundles that are sufficient to uniquely distinguish between individuals in at least 95% of cases involving the US population.

TEM FOCUS

However, the FICAM TFS Program recognizes that the NASPO IDPV study, while a starting point, is just the start and not the end. As such, we are convening this TEM to:

• Articulate the identity federation needs of government agencies as it relates to identity resolution that balances identity assurance, privacy respecting approaches and cost-effectiveness
• Solicit feedback from participants with expertise in identity proofing and attribute management on publicly sharable data, studies and approaches that enable unique identity resolution within the U.S. population for the explicit purpose of delivering high value online government services
• Identify short-comings in current studies on this topic, discuss factors to mitigate them, and identify areas to focus on for near term and future research investments

REQUEST FOR DISCUSSION TOPICS and STUDIES

If you have expertise in identity resolution, identity proofing and related privacy aspects, and have data-backed research and results to share on this topic, we are interested in hearing from you. Please contact us at TFS.EAO@gsa.gov by COB 4/16/14 with your proposed discussion topic.


DRAFT AGENDA for 05/01/2014

09:00 AM - 09:30 AM Attendee Check-In
09:30 AM - 10:10 AM Welcome & TEM Overview/Goals/Level Set

10:15 AM - 11:10 AM Agency Viewpoint Panel on Identity Resolution + Privacy
[CMS, DHS, GSA, NIST, SSA, State Dept - Moderated by NIST]
11:15 AM - 11:45 AM Audience Discussion / Q&A

11:45 AM - 01:00 PM LUNCH (On your own) & NETWORKING

01:00 PM - 01:55 PM Industry Viewpoint Panel on Identity Resolution + Privacy
[CertiPath, Experian, ID/DataWeb, LexisNexis, SecureKey, Socure, Symantec - Moderated by NIST]
02:00 PM - 02:30 PM Audience Discussion / Q&A

02:30 PM - 02:45 PM BREAK

02:45 PM - 03:40 PM Joint Panel on Business Models / Cost / Innovation
[Agency & Industry Panelists - Moderated by Kantara Initiative]
03:45 PM - 04:15 PM Audience Discussion and Q&A

04:15 PM - Event Wrap-up

Sign up for our notification list @ http://www.idmanagement.gov/trust-framework-solutions to be kept updated on this and future FICAM TFS news, events and announcements.


:- by Anil John
:- Program Manager, FICAM Trust Framework Solutions

ICAM Information Sharing Day and Vendor Expo - Spring 2014

We are pleased to announce that attendee registration is now open for the Spring 2014 ICAM Information Sharing Day and Vendor Expo. 

The event will be held at the GSA Central Office location (1800 F Street NW, Washington, DC 20405) on Wednesday, April 16th  with registration beginning at 8:00 a.m. and closing remarks wrapping up at 3:15 p.m.

This event will consist of panel discussions, government-wide updates, interactive breakout sessions, a vendor expo with representation from over 20 vendors, and dedicated time for informal networking. 

The theme of this year’s ICAM Day will focus on Leveraging ICAM to Address Cybersecurity Threats, and will provide a variety of insights for ICAM professionals.  Session topics will include enabling secure information sharing, addressing mobile security with ICAM, and responding to the impacts of NIST guidelines to ICAM. 

This event is open to government employees, contractors, and industry representatives (e.g., vendors).

Space is limited and early registration is recommended. Online registration at http://www.gsa.gov/portal/content/188995

:- Deb Gallagher, Paul Grant & Leo Scanlon
:- ICAMSC Co-Chairs

HOW-TO: Become a FICAM TFS Approved Identity Service

The FICAM Trust Framework Solutions (TFS) Program is focused on enabling and supporting the security, privacy and interoperability requirements of Government to Citizen (G2C) and Government to Business (G2B) online services.

The assurance needs of such services range from level 1 to level 4, with the majority of services requiring assurance levels 2 and/or 3. The following is a high level overview of the FICAM TFS Approval Process for Identity Services at assurance levels 2 and 3:

Step 1 in the above process can be initiated by contacting the FICAM TFS Program @ TFS.EAO@gsa.gov

A complete overview of the program and of the end-to-end approval processes can be found in the "FICAM Trust Framework Solutions Overview" and "Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services" documents which also has information on:

• Streamlined level 1 approval process
• Fast-track approval process for Financial Institutions required to implement a Customer Identification Program by Government regulators
• High assurance approval process for PKI/Level 4 identity services that leverage existing Federal PKI Policy Authority processes

RELATED INFORMATION

• FICAM Trust Framework Solutions Program
• FICAM TFS Component Identity Services Terminology
• FICAM TFS Approved Identity Services

:- by Anil John
:- Program Manager, FICAM Trust Framework Solutions

FICAM TFS Component Identity Services Terminology

As part of a recent update, the concept of component identity services was incorporated into the FICAM Trust Framework Solutions (TFS). The component identity service model "separates the functions of authentication and attribute providers".

This is supported by an industry trend whereby these functions are now offered by separate service providers. This trend has been driven by the fact that:

• Vendors have focused their offerings according to their core strengths, which leads to improved quality of service for agency Relying Parties.
• Some identity solution architectures require or desire the use of separated services, which offers agency Relying Parties a greater quantity of service choice and increased flexibility in selecting only those services that are needed from an external provider.

The model, shown below, utilizes the following OMB and NIST terminology:

• Token: Something that an individual possesses and controls that is used to authenticate the individual
• Tokens are possessed by an individual and controlled through one or more of the traditional authentication factors (something you know, have, or are)
• Identity: A set of attributes that uniquely describe an individual within a given context
• Credential: An object or data structure that authoritatively binds an identity to a token possessed and controlled by an individual

NOTE: The above model is based on assurance and identity concepts that have been discussed in multiple jurisdictions and communities. In particular, the FICAM TFS Program would like to acknowledge the contributions of the Canada TBS and the Kantara IAWG.

The value of the model lies in the flexibility possible in combining the various functions as part of an industry service offering.

Within the framework of the FICAM TFS Program, the following three combinations are recognized:

A Credential Service Provider, which offers:

• Token Management Services
• Authentication Services
• Identity Proofing Services
• Attribute Validation Services

A Token Manager, which offers:

• Token Management Services
• Authentication Services 

An Identity Manager, which offers:

• Identity Proofing Services
• Attribute Validation Services

It should be noted that in all three cases, consent services are implementation specific and driven by policy.

The FICAM TFS Program recognizes that, especially in the private sector, identity service functions may be conducted by separate and independent entities that have relationships based on contracts as well as laws and regulations. As such, it supports a flexible conceptual model that brings together token managers, identity managers and credential service providers.

:- by Anil John

FICAM Trust Framework Solutions (TFS) Program - Updated

The FICAM Trust Framework Solutions (TFS) is the federated identity framework for the U.S. federal government. It includes guidance, processes and supporting infrastructure to enable secure and streamlined citizen and business facing online service delivery.

For the first time since the inception of the Program in 2009, we are releasing a comprehensive update to the Program to incorporate Agency implementation feedback, ongoing lessons learned regarding the operational needs of shared service initiatives such as the Federal Cloud Credential Exchange (FCCX), as well as updates made as a result of changes in the private sector marketplace of identity services.

The FICAM Trust Framework Solutions Overview provides a holistic overview of the FICAM TFS Program

• Description of the components that make up the TFS Program
• The TFS role in supporting Government-wide policy and National Strategy implementations
• TFS and its implementation by Government Agencies
• TFS fast-track process for Financial Institutions required to implement a Customer Identification Program by Government regulators 
• Relationship to the FICAM Testing Program for on-premise vendor solutions that implement FICAM protocol profiles 

The components of the FICAM TFS Program are:

• The Trust Framework Provider Adoption Process for All Levels of Assurance describes the process by which the TFS Program evaluates and adopts commercial Trust Frameworks for use by the U.S. federal government
• Overview of the Trust Framework Adoption Process
• Incorporation of the privacy trust criteria into the Trust Framework adoption process
• Updated trust criteria to incorporate NIST SP-800-63-2
• Streamlined LOA 1 Trust Criteria
• Introduction of ongoing verification as an OPTIONAL trust criteria
• Support for Component Identity Services, and associated standardized terminology
• TFS Program's relationship to entities (CSPs etc.) that are assessed and evaluated by an adopted Trust Framework Provider
   
• The Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services makes explicit the requirements that identity services need to satisfy in order to offer their services to the U.S. federal government
• Clarification of approval decision authority of the FICAM TFS Program
• Explicit testing and verification of service interfaces to assure conformance to approved protocols and profiles
• Requirement to implement tested interfaces by the solution provider when offering the service to Government
• Standards based attribute requirements to enable identity resolution by Government relying parties at LOA 2 and greater
   
• The Identity Scheme and Protocol Profile Adoption Process describes the process by which protocol profiles are created, adopted and used by the government to ensure that the RP application and the CSP communicate in a secure, interoperable and reliable manner.
• Updated to allow the flexibility for Government to adopt protocol profiles created by industry, provided it meets Government needs for security, privacy and interoperability
• Standardized assurance level URIs for use in protocol profiles
   
• The Relying Party Guidance for Accepting Externally Issued Credentials provides guidance to Agencies on leveraging federated identity technologies to accept externally issued credentials
   
• The E-Governance Trust Services Certificate Authority provides a certificate issuance capability that supports the federated identity use cases of Agencies that require endpoint and message level protections
   
• The E-Governance Trust Services Metadata Services (EGTS Metadata Services), once implemented and made available, provides a trusted mechanism for the collection and distribution of metadata to enable identity federation capabilities

All of the above documents, except for the Relying Party Guidance and the EGTS CA Concept of Operations, are currently in DRAFT status while we seek feedback from our Public and Private sector stakeholders.

For those outside the U.S. federal government, there will be an opportunity to engage in a facilitated discussion and Q&A with the FICAM TFS Program Manager during the December 4, 2013 meeting of the IDESG Trust Framework and Trustmark (TFTM) Committee.

UPDATE 2/7/2014:  The updates to the FICAM TFS have been finalized and are now available.

RELATED INFO

• FICAM Trust Framework Solutions Overview
• Trust Framework Provider Adoption Process for All Levels of Assurance
• Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services
• Identity Scheme and Protocol Profile Adoption Process
• Relying Party Guidance for Accepting Externally Issued Credentials
• E-Governance Trust Services Certificate Authority

:- by Anil John
:- Program Manager, FICAM Trust Framework Solutions

Federal ICAM Information Sharing Day and Vendor Expo

The Federal ICAM Information Sharing Day and Vendor Expo will take place on Tuesday, June 18, 2013 from 8:00 a.m. to 4:00 p.m.

This event will consist of presentations, panel discussions, and breakout sessions on pressing issues facing the Federal Government’s ICAM programs today. Attendees will also benefit from a vendor exhibit, showcasing technology solutions to satisfy ICAM needs.

This free event is open to government employees, contractors, and industry representatives (e.g., vendors).

LOGISTICS/VENUE INFORMATION  

The ICAM Information Day and Vendor Expo will be held on June 18, 2013 from 8:00 a.m. to 4:00 p.m. at the following location:

GSA One Constitution Square Building
1275 First Street NE, Washington

REGISTRATION INFORMATION

Those attending ICAM Information Day and Vendor Expo should register at the following site: http://www.gsa.gov/ICAMexpo

Special Information for Vendor Registration

If you plan to participate in the Spring 2013 ICAM Day’s Vendor Expo, please complete the registration process and choose your affiliation as a "Vendor". Upon registration, you will be contacted by the conference coordinator to provide additional details for exhibit coordination. ICAM Day vendor registration is free, but limited to the first 25 vendors.

AGENDA

Please note that the agenda is subject to change.

Timeframe	Description	Speaker
8:00 – 9:00	Registration
9:00 – 9:10	Welcome and Opening Remarks	Deb Gallagher (GSA) Paul Grant (DoD)
9:10 – 9:30	FIPS 201/FICAM Testing Program Update	Chi Hickey (GSA)
9:30 – 10:30	Panel Discussion: Attribute Exchange and Information Sharing in Action Panelists will share the latest updates on technology and approaches for attribute exchange and the importance of information sharing and safeguarding to the national cybersecurity agenda.	Anil John (GSA), Moderator David Coxe (ID DataWeb, Inc.) Dieter Schuller (Radiant Logic) Nathaniel (Ted) Sobel (DHS) John F. Wandelt (GTRI) Martin Smith (PM-ISE)
10:30 – 11:30	Panel Discussion: Externalizing Authentication Panelists will provide insights into how Agencies can externalize authentication using shared services. Participants include members of the OMB MAX Authentication Team as well as members of the Federal Cloud Credential Exchange (FCCX) Team.	Anil John (GSA), Moderator FCCX Team MAX.GOV Team
11:30 – 12:30	Lunch break (lunch not provided)
12:30 – 4:00	Vendor Expo
12:30 – 1:15	Breakout Session 1  FICAM Procurement [Government Only. PIV Required for Entrance] An interactive discussion with agencies with regards to challenges and gaps in procuring PACS components/systems from the Approved Products List. Potential discussion topics include breakdown of new PACS categories, severity levels/risks, ICAM test cards, development of acquisition language that complies with policy and meets agency needs, and defining acquisition requirements for relevant ICAM systems. Driving Mobility Forward with ICAM A discussion of current trends and technology within the mobile environment. Potential discussion topics include contactless, enterprise architecture, and strategies for supporting a mobile, remote workforce. Enterprise PACS Solution Best Practices A discussion of lessons learned, solutions, and processes to support implementation of agency-wide enterprise PACS and PIV-enablement. Potential discussion topics include managing risk, designing an enterprise PACS, and migrating to strong authentication using the PIV Card. Realizing the Value of ICAM A discussion of how to plan, implement, and measure an agency ICAM program focused on efficiency, cost-savings, and value. Potential discussion topics include the strategic importance of ICAM as a mission enabler, messaging ICAM to leadership, prioritizing and securing investments, and selecting cost-effective design and solutions for implementation.
1:20 – 2:05	Breakout Session 2  FICAM Procurement [Government Only. PIV Required for Entrance] An interactive discussion with agencies with regards to challenges and gaps in procuring PACS components/systems from the Approved Products List. Potential discussion topics include breakdown of new PACS categories, severity levels/risks, ICAM test cards, development of acquisition language that complies with policy and meets agency needs, and defining acquisition requirements for relevant ICAM systems. Driving Mobility Forward with ICAM A discussion of current trends and technology within the mobile environment. Potential discussion topics include contactless, enterprise architecture, and strategies for supporting a mobile, remote workforce. Enterprise PACS Solution Best Practices A discussion of lessons learned, solutions, and processes to support implementation of agency-wide enterprise PACS and PIV-enablement. Potential discussion topics include managing risk, designing an enterprise PACS, and migrating to strong authentication using the PIV Card. Realizing the Value of ICAM A discussion of how to plan, implement, and measure an agency ICAM program focused on efficiency, cost-savings, and value. Potential discussion topics include the strategic importance of ICAM as a mission enabler, messaging ICAM to leadership, prioritizing and securing investments, and selecting cost-effective design and solutions for implementation.
2:10 – 2:35	Accelerating the implementation timeline and reducing the cost of PIV in application by using Cloud services	Xceedium Amazon Web Services
2:35 – 3:35	Panel Discussion: Tackling an Evolving Mobile Environment Panelists will discuss approaches for addressing common mobility and security-related challenges. Panel will include agency representatives at different stages of program planning and execution, as well as participants from policy and technical viewpoints.	Donna Dodson (NIST), Moderator John Hickey (DOD/DISA) Tom McCarty (DHS) Adam Zeimet (USDA)
3:35 – 3:55	OMB ICAM Update [Government Only. PIV Required for Entrance]	Carol Bales (OMB)
3:55 – 4:00	Closing Remarks	Salomeh Ghorbani (GSA)

FICAM Trust Framework Solutions TFPAP Update v1.1.0

The FICAM Trust Framework Solutions (TFS) Trust Framework Provider Adoption Process (TFPAP) has been updated to v1.1.0 (PDF).

This is a point update that does not change any of the existing TFP processes but instead:

• Acknowledges an existing internal Government process in order to recognize non-federally issued PKI providers, who are cross-certified with the Federal Bridge, as approved Credential Service Providers under the FICAM Trust Framework Solutions umbrella. 
• Incorporates the Trust Framework Solutions (TFS) "branding" under FICAM. 

The relevant text that acknowledges the existing processes is the following:

The FICAM Trust Framework Solutions (TFS) cover remote electronic authentication of human users to IT systems over a network. It does not address the authentication of a person who is physically present.

The TFS is inclusive of externally issued PKI and non-PKI credentials at OMB Levels of Assurance 1, 2, 3 and 4:

• For PKI based credentials the TFS recognizes the Federal PKI Policy Authority (FPKIPA) as a TFS approved Trust Framework Provider and will rely on its proven criteria and methodology for non-Federally issued PKI credentials. 
• For non-PKI credentials, each Identity Provider and TFP must demonstrate trust comparable to each of five categories (registration and issuance, tokens, token and credential management, authentication process, and assertions) for each Level of Assurance it wishes its credentials trusted by government applications (including physical access control systems).

The other point to note is the establishment of the Trust Framework Solutions "branding" under FICAM to acknowledge the C2G and B2G aspects that FICAM is responsible for (FICAM in the Federal Government covers areas beyond C2G and B2G). At a high level, we are bucketing the C2G and B2G pieces under the TFS umbrella and are expecting the TFS, in the near term, to "own" the:

1. Trust Framework Provider Adoption Process (TFPAP)
2. The Relying Party Guidance on Accepting Externally Issued Credentials (Currently under internal review)
3. FICAM TFS Trust Mark (Future)

RELATED INFO

• FICAM TFS Trust Framework Provider Adoption Process v1.1.0 (PDF)

:- by Anil John

Federal ICAM Information Sharing Day and Vendor Expo

The Federal Identity, Credential and Access Management Subcommittee Announces the ICAM Information Sharing Day and Vendor Expo

On November 27^th, the Identity, Credential, and Access Management Subcommittee (ICAMSC) will hold the ICAM Information Sharing Day and Vendor Expo. The focus of this ICAM Information Day and Vendor Expo will be the use of PIV credentials in systems such as Physical Access Control Systems (PACS), Logical Access Control Systems (LACS), mobile devices and cloud services. The participating vendors will demonstrate their latest information assurance and security products and services related to the use of the PIV.

LOGISTICS/VENUE INFORMATION  

The ICAM Information Day and Vendor Expo will be held on November 27, 2012 in coordination with the Smart Cards in Government Conference which will be held November 28^th – 30^th at the following location:

Washington Convention Center
801 Mount Vernon Place Northwest, Washington, DC 20001

There will be no fee for federal employees and contractors with PIV attending the ICAM Information Day event.

REGISTRATION INFORMATION

Those attending ICAM Information Day and Vendor Expo should register at the following site: www.GovSmartID.com

AGENDA

Please note that the agenda is subject to change.

Timeframe	Description	Speaker
9:00 – 9:15	Welcome and Opening Remarks	Deb Gallagher (GSA) and/or Paul Grant (DoD)
9:15 – 10:00	Keynote Address: Enabling CAC/PIV in a Mobile Government Workforce	Rob Carey (DoD)
10:00 – 12:00	Opening of the Vendor Exhibits
12:00 – 12:30	Lunch break (lunch not provided)
12:30 – 1:00	Security Policy and Standards for Use of Mobile Devices on Federal Networks	Carol Bales (OMB)/ Donna Dodson (NIST)
1:00 – 1:30	Expectation of PIV use with Logical Access Systems	Bill Erwin (DoD)
1:30 – 2:00	Expectation of PIV use with Mobile Devices	Deb Gallagher (GSA)
2:00 – 2:30	Expectation of PIV use with Physical Access Systems	Will Morrison (FAA)
2:30 – 3:00	Afternoon Break (vendor exhibits will remain open)
3:00 – 3:15	FIPS 201-2 Status	Hilde Ferraiolo (NIST)
3:15 – 3:30	Update on FY FISMA Metrics for PIV Use	Glen Lee (DOE)/ Rajeev Pillai ( GSA)
3:30 – 3:45	Trust Framework Update	Anil John (GSA)
3:45 – 4:15	Open Discussion	Deb Gallagher (GSA) and/or Paul Grant (DoD)
4:15 – 4:30	Closing Remarks	Deb Gallagher (GSA) and/or Paul Grant (DoD)

Challenges in Operationalizing Privacy in Identity Federations - Part 3

Part 1 of this series discussed the data minimization principles of anonymity, unlinkability and unobservability and their relationship to identity federation. Part 2 of this series walked through a proxy architecture that provides those principles in a federated authentication system. In this blog post, I would like to expand the discussion of the proxy architecture to include user enrollment and see how the data minimization principles are affected by the need for verified attributes.

In the proxy architecture, when a user arrives for the first time at the relying party (RP) after being authenticated by the IdP/CSP, the RP knows:

1. A trusted IdP has authenticated the user, 
2. The Level of Assurance (LOA) of the credential used, and 
3. The Persistent Anonymous Identifier (PAI) associated with the credential of the authenticated user. 

Assumption: As part of the identity proofing and credential issuance process, the IdP/CSP has collected and verified information about the user (which is a requirement for LOA 2+ scenarios).

The RP starts the user enrollment process by collecting both a shared private piece of data (e.g. account #, access code, SSN etc.) that represents a claim of identity and a set of information (e.g. Name, Address, DOB etc.) that can be used to prove that claim from the user. The data elements that are collected by the RP needs to be a subset of those verified and collected by the IdP/CSP as part of the identity proofing and credential issuance process.

The RP then initiates the attribute verification process:

• The request is made via the proxy to maintain the PAI to PPID mapping and the PPID to CID mapping
• The request is for a MATCH/NOMATCH answer and NOT a "Give me all the attributes you have collected during identity proofing"
• The shared private data (e.g. Account #, Access Code, SSN etc.), which is ALREADY in the RP system, is NOT sent to the IdP/CSP

If the response that comes back from the IdP/CSP is positive, the RP:

• Uses the shared private piece of data to pull up the associated user record 
• Checks to see if the verified attributes returned match those in the user record
• If they match, the RP links the PAI to the associated user record locator a.k.a. Program Identifier (PID)

Critical points to note here are that the IdP still does not know which RP the user went to, the RP still does not know which IdP the user is coming from, but the Proxy now has visibility into the attributes flowing through it.  As such, it is critical to make sure that a security policy backed by an independent audit and verification regime is put in place to assure that the proxy does not collect, store or log the attribute values flowing through it.

We would be interested to hear about how this architecture can be improved or modified to enhance its privacy characteristics.

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Challenges in Operationalizing Privacy in Identity Federations
• Challenges in Operationalizing Privacy in Identity Federations - Part 2
• How To Implement the Technical Aspects of an Identity Oracle
• Nat Sakimura: Privacy Enhancement for Open Federated Identity/Access Management Platforms (PEOFIAMP) R&D Project

:- by Anil John

What are FICAM Technical Profiles and Identity Schemes?

A critical technology underpinning of the FICAM Trust Framework Solutions process is the need to enable the ability of the federal government to utilize industry standards. This blog post provides an overview of the FICAM protocol profiling work that enables the federal government to utilize industry standards in a secure and interoperable manner.

As anyone who has been involved in technical protocol standards development will know, a finalized standard is often a compromise. In particular there is a great tension around the need to provide flexibility and extensibility, security and privacy, and interoperability in the standards development process. The result often ends up being a standards document that provides multiple ways of accomplishing the same thing, all of which are "compliant" to the standard but often may not be interoperable.

For the federal government to utilize industry standards, they need to be widely deployed by multiple vendors, interoperable, and meet the security and privacy policy requirements articulated by authoritative federal government bodies such as OMB, NIST, CIO Council etc.

This requires the standard to undergo a "Profiling" process that:

• DOES NOT change the standard in any way
• DOES take into consideration security requirements of the federal government
• DOES take into consideration privacy requirements of the federal government
• Locks down the MUSTs, SHOULDs, SHOULD NOTs etc. in the specification language so that there is assured interoperability between profile implementations
• Results in a "Test-able" product

When this process was initially envisioned, we were very much focused on authentication.  As such, the end result of the profiling process was the development of "portable identity schemes" which enabled the use of identity federation protocols to convey information for the purpose of authentication.

The "FICAM Profile of SAML 2.0 for Web SSO (PDF)" and the "FICAM OpenID 2.0 Profile (PDF)" are clear examples of portable identity schemes that incorporate standards profiling. We will continue to utilize identity schemes as an item that an identity provider needs to implement in order to interoperate securely with a federal government relying party (service provider).

As our requirements have grown, we have found it necessary to expand beyond authentication to areas such as attribute exchange, authorization and more. Profiles such as the "SAML 2.0 Identifier and Protocol Profiles for BAE v2.0 (PDF)" and "SAML 2.0 Metadata Profile for BAE v2.0" stand on their own and are not authentication related.

We expect this to continue and expand in the future.

As an example, the currently underway work on the "FICAM Profile of OAUTH 2" is not an identity scheme, given that OAUTH 2 requires an additional authentication layer to convey identity information. Once the OAUTH 2 profiling is complete, we will be working to identify and profile the pieces that make up that additional identity layer. The combination may result in a FICAM approved portable identity scheme that utilizes OAUTH 2.

In short, going forward we expect to continue our work to profile protocol standards such that they are usable by themselves, as well as use profiles as building blocks to enable portable identity schemes.

RELATED INFORMATION

• FICAM Technical Profiles and Identity Schemes

:- by Anil John

How To Implement the Technical Aspects of an Identity Oracle

In the age of attributes, personal data, and data brokers, the concept of Identity Oracles and how they can help to mediate between diverse entities is something worthwhile to consider.  This blog post provides a short introduction to the Identity Oracle concept and discusses the work FICAM is starting in order to address the technical intersection of Identity Oracles and Attribute Providers via a new Backend Attribute Exchange (BAE) Protocol Profile.

The original definition of an "Identity Oracle" which was coined back in 2006 by Bob Blakley, the current NSTIC IDESG Plenary Chair, is:

• An organization which derives all of its profit from collection & use of your private information…
• And therefore treats your information as an asset…
• And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information…
• Thus keeping both the Relying Party and you happy, while making money.

While that applies to commercial entities pretty well, let me tweak that a bit for the Government sector:

• An organization which is the authoritative source of some of your private information…
• And is constrained by law and policy to safeguard your information…
• And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information, with your consent and without disclosing your information…
• Thus keeping both You and the Relying Party happy, while enabling you to conduct safe, secure and privacy preserving online transactions

A potential technical interaction between the three entities could be:

1. Person establishes a relationship with the Identity Oracle. The Identity Oracle provides the person with token(s) that allow the person to vouch for his relationship with the Identity Oracle in different contexts
2. When the Person needs to conduct a transaction with a Relying Party, he presents the appropriate token, which establishes his relationship to the Identity Oracle
3. The Relying Party asks the Identity Oracle “Am I allowed to offer service X to the Person with a token Y from You under condition Z?”. The Identity Oracle answers “Yes or No”

Conceptually, this type of question is something you would want to ask an Attribute Provider, but current protocols for attribute query and response are really not set up to enable this type of capability.  So putting aside the business and policy aspects, which are huge, a technical piece that needs to happen is to define how the interaction in step (3) above can happen using widely deployed protocols.

Based on multiple information sharing use cases that have come up, and an internal review of need and value, we have decided to address this requirement within FICAM by working to define a "XACML 3.0 Attribute Verification Profile for BAE 2.0":



The intent of this effort will be to profile XACML 3.0 messages on the wire, not for authorization, but to enable the construction of a verification request and corresponding response, while keeping the message level and transport level security mechanisms consistent between this new profile and the original SAML 2.0 Identifier & Protocol Profile for BAE 2.0.

RELATED POSTS

• Attributes Anytime, Anywhere. Extending BAE to Support New Protocols
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Challenges in Operationalizing Privacy in Identity Federations - Part 2

Federation implementations enabling privacy enhancing characteristics such as anonymity, unlinkability and unobservability are something that we are very interested in for Government service delivery. This blog post describes one such approach using a proxy mechanism between the identity provider and the relying party and articulates some of the trade-off's inherent in such an approach.

The typical identity federation scenario with an externalized Identity/Credential Provider and a Relying Party looks something like this:

• User's credential identifier (CID) is not released to RP. FICAM Identity Schemes require a Pairwise Pseudonymous Identifier (PPID) to limit the loss of anonymity and unlinkability; IdP keeps track of that mapping internally
• The Program Identifier (PID) is a user record identifier that only the RP know about, and the RP establishes the one-time PPID to PID mapping via the user enrollment process
• The IdP knows about the RP the user is interacting with so there is no mitigation for the loss of unobservability

If implementing this using SAML 2.0, this would be the classic SAML Web SSO Sequence Diagram with a persistent identifier for NameID:



One approach that would bring additional privacy enhancing characteristics into this mix is the implementation of a Proxy between the Identity Provider and the Relying Party:

• CID to PPID mapping is the same as before. Limits loss of anonymity and unlinkability
• When a PPID comes into the proxy, it generates an associated Persistent Anonymous Identifier (PAI) which is then released to the RP. The proxy manages the persistent PPID to PAI mapping. 
• Limits loss of unobservability, since IdP has no visibility into which RP the user has gone to or the identifier that they are using at that RP 
• RP know that a trusted IdP authenticated the user and the associated LOA level but nothing more
• RP manages the PAI to PID mapping
• The proxy knows of the IdP and the RP but knows nothing other than the PPID and the PAI
• Forensics requires coordination across IdP, Proxy and RP

As an aside, I would like to acknowledge our colleagues at TBS Canada for how they defined PAI and PID (PDF); I saw no value in coming up another term to describe the same items, so decided to simply leverage their definitions.

If implementing this in SAML 2.0, the sequence diagram with the proxy taking on both IdP and RP roles as needed would look like:



This architecture works brilliantly as a privacy enhanced credential mediation service and it can very easily be implemented using current technical protocols. But it does require the responsibility for identity proofing (before enrollment) to rest with the RP. So some questions that need to be explored are:

• How can the RP gain access to the attributes collected during the identity proofing stages by the IdP/CSP?
• Can all or most of the privacy characteristics still survive when attribute movement comes into play for user enrollment?

Any insights and lessons learned on working with this type of architecture would be appreciated.

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Challenges in Operationalizing Privacy in Identity Federations
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Challenges in Operationalizing Privacy in Identity Federations

A critical part of the job of an identity/information management professional is to operationalize privacy in the systems they architect, build and deploy. Unfortunately, it is easier to make that statement than to come up with a rigorous and repeatable process to do it. It is hard because privacy is contextual in nature, and data often moves across organizational and system boundaries where shared context may not exist. This blog post is an attempt to articulate some definitions and considerations regarding operationalizing privacy within the narrow realm of identity federation.

NIST, in its DRAFT SP 800-130 "A Framework for Designing Cryptographic Key Management Systems" (PDF) articulates the three privacy characteristics (Section 4.7) of Anonymity, Unlinkability and Unobservability:

An information management and security policy may state that users of the secure information processing system can be assured of anonymity, unlinkability, and unobservability, if these protections are required. Anonymity assures that public data cannot be related to the owner. Unlinkability assures that two or more related events in an information processing system cannot be related to each other. Finally, unobservability assures that an observer is unable to identify or infer the identities of the parties involved in a transaction.

In his write-up of the NIST CKMS Workshop, Dr. Francisco Corella had this to say as it relates to identity federation:

"[...] One way of reducing the number of passwords to be remembered is to rely on a third-party identity provider (IdP), so that one password (presented to the IdP) can be used to authenticate to any number of relying parties. The Federal Government allows citizens to access government web sites through redirection to several Approved Identity Providers.

But third party login has privacy drawbacks. In usual implementations, anonymity is lost because the relying party learns the user’s identity at the IdP, unlinkability is lost by the use of that identity at multiple relying parties, and unobservability is lost because the IdP is informed of the user’s logins. Profiles of third-party login protocols approved for citizen login to government sites mitigate some of these drawbacks by asking the identity provider to provide different identities for the same user to different relying parties. This mitigates the loss of anonymity, and the loss of unlinkability to a certain extent. (Relying parties by themselves cannot track the user, but they can track the user in collusion with the IdP.) But the loss of unobservability is not mitigated, because the IdP is still informed of the user’s activities.

I believe that the Government should work to develop and promote authentication methods that eliminate passwords while preserving anonymity, unlinkability and unobservability."

Agreed.

The Fair Information Practice Principles (FIPPs) are a core part of the NSTIC vision for the Identity Eco-System, and more concretely, a critical part of the Federal Government's implementation of that vision (FICAM). The FICAM Identity Schemes (i.e. Protocol Profiles for Authentication) require the use of pair-wise pseudonymous identifiers to mitigate the loss of anonymity and loss of unlinkability. The loss of unobservability is still very much a concern, which is why as we move out on our FCCX initiative, we are specifically calling out the issue of "panopticality" as something that is critical for us to address.

We are investing both attention and resources to this area, but have little desire to build a closed eco-system of proprietary technologies with limited interoperability that becomes expensive technology road-kill due to lack of support in the marketplace.

We need the help of standards bodies, technology vendors and other stakeholders in making sure the ability to support these privacy characteristics are baked into the current and future generation of identity protocols and standards. Even more so, we need support for these privacy enhancing characteristics to be adopted and used in the implementations of the same protocols and technologies by the identity thought leaders in this space so that Government can leverage and utilize them as part of delivering Citizen facing services.

RELATED POSTS

• Challenges in Operationalizing Privacy in Identity Federations - Part 2
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

How To Collect and Deliver Attributes to a Relying Party for User Enrollment

In order for user enrollment to work at a Relying Party (RP) it needs a shared private piece of data that represents a claim of identity (e.g. SSN, Drivers License #) and a set of information that can be used to prove the claim. The manner in which the RP obtains the latter depends to a great degree on the identity verification model that is used. This blog post describes the steps and considerations regarding attribute movement for the purpose of user enrollment.

The steps in this process, from the perspective of the RP, are:

1. Determine the minimal set of attributes (attribute bundle) needed to uniquely identify a person, map them into an existing record at the RP or create a new record if it does not exist
2. If the attributes are Personally Identifiable Information (PII), implement the necessary protections (both policy and technology) needed to safeguard them during collection, transit, and at rest
3. Determine who will collect, verify and bind the attributes to an identifier, and if the assurance level of that binding is acceptable
4. Determine the secure mechanism needed to move the attributes from the entity that collected them to the Relying Party

1. Determine the minimal set of attributes

• What is the minimum set of attributes needed to uniquely identify a person within a system?
• Can we standardize this "attribute bundle" across multiple systems? e.g. Does the combination of Social Security Number, Date of Birth, State of Residence serve to uniquely identify  a person? More? Less?

2. Implement PII Protection on collected attributes 

• Has a Privacy Impact Assessment been done that includes clear identification of the data needed and collected?
• Do you have the authority to collect this information? How will you track and verify user consent?
• Have you implemented technical and policy protections on PII information as required?

3. Who will collect and verify the attributes?

• Will the attributes be collected and verified by an Identity/Credential Provider or a Registration/Identification Service?
• Will the attributes be collected by the Relying Party and be verified directly or by leveraging a third party service?
• Is the verification of attributes and the binding to an identity comply with NIST 800-63-1(PDF) identity proofing requirements?
• If the verified attributes provided by the IdP/CSP/AP are not sufficient, do you need to implement the ability to request the data directly from the citizen or implement an attribute request/verification capability with a third party service? 

4. How will you securely move the attributes?

• How will you move the verified attributes from an IdP/CSP/AP to the RP?
• Will the attributes be sent every time by the IdP/CSP/AP to the RP? Is there a mechanism to provide a hint regarding first time enrollment?
• Does support for using an out-of-band attribute call to the IdP/CSP/AP exist with all entities in the flow? If needed, what will you use as the identifier?
• Does the ability to capture and pass consent regarding attribute release exist?

One other attribute movement mechanism that is often used by Enterprise as an IdP, is to out of band provision an RP via some sort of an Identity Bridge mechanism. That particular use case comes into play when you are connecting the Enterprise to a SaaS Provider. That use case is out of scope.

Feedback on how you are implementing these types of capabilities in your Enterprise would be appreciated. Are there additional or different approaches or considerations?

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• Assurance Level Escalation and Government Relying Parties
• Challenges in Operationalizing Privacy in Identity Federations - Part 3

:- by Anil John

Attributes Anytime, Anywhere. Extending BAE to Support New Protocols

The Backend Attribute Exchange (BAE) Capability implements a pure Attribute Provider and, by deliberate design, does not provide any authentication functionality. The current technical implementation of the BAE supports a secure FICAM Profile of SAML 2.0 Assertion Query and Response (PDF) which is bound to SOAP.   In this blog post, and as a thought exercise, I am going to walk through some of the approaches, considerations and use cases in how we could extend the BAE to support additional protocols for attribute exchange.



XACML

XACML is a protocol that is well understood by the Government community and at v3.0 is a mature standard that has support in multiple COTS products. The use case that I am envisioning is driven more by the need to provide a capability to verify self-asserted attributes rather than pure attribute retrieval:

1. An entity needs to ask a question and asserts a set of attributes in support of that question . e.g. "Is this person allowed to drive a car in Maryland?" + Data found on a Driver's License
2. There are privacy and/or data security concerns regarding the attributes such that the attribute provider cannot respond with the verified attribute values from the authoritative source
3. The attribute provider responds with a boolean "Yes|No" and clarification/error data as appropriate

In order to accomplish this, you could profile XACML messages on the wire, NOT for Authorization, but to construct a verification request and a corresponding response given that XACML 3.0 provides:

• The ability to send multiple attributes and values in and the ability to get a Yes|No or a Match|NoMatch decision back
• Attribute Categories (pre-defined and custom) for <Subject>, which can carry the self-asserted attributes of the subject, and <Resource>, which can be used to route the request to the appropriate authoritative sources
• The request message allows for capturing the consent of the <Subject> for attribute release
• XACML Advice that can be returned to inform the requester of errors (Don't want to use obligations here given that the standard requires that PEP must discharge obligations)
• Ability to layer in cross-cutting security functionality, at both the message and transport level using existing infrastructure

The BAE could potentially support this as an additional interface that can in effect act as the technical pieces of an Identity Oracle.

OAUTH 2

OAUTH 2 is a new protocol which, in my mind, has relevance to the Government community because of how it could be utilized to layer in identity into mobile devices. This use case is more about implementing a pure Attribute Provider functionality using a profile of OAUTH 2 rather than supporting the full OAUTH 2 IdP functionality.

If you take a look at the work that has been done on OpenID Connect (OIDC) as an example, they have defined what is called a UserInfo Endpoint. This endpoint is simply an OAUTH 2 Protected Resource with some specific communication semantics:

• It requires that an Access Token be sent to it (i.e. UserInfo Request is sent as an OAUTH2 Bearer Token)
• It returns attributes in cleartext JSON or if needed as a signed/encrypted JWT (i.e. UserInfo Response)

One thing I am currently not sure about is if the OpenID Connect specification constrains in any way the implementation of the UserInfo Endpoint to the OIDC Identity Provider (i.e. the entity that actually authenticates the end user), or if it in practice can provide a flow/ability to support a "stand-alone" UserInfo endpoint.

The BAE could potentially support this as an additional Attribute Provider interface, and depending on the Authorization Server (OpenID Connect) or Authorization Manager (UMA) based OAUTH 2 flows, could support the appropriate semantics in the request and response.

Comments and perspectives on both are welcome!

RELATED POSTS

• From AAES to BAE - Implementing Collection and Sharing of Identity Data
• What is new with the BAE Operational Deployment?
• Shared Services and Government as Attribute Service Provider

:- by Anil John

From AAES to BAE - Implementing Collection and Sharing of Identity Data

The Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance (PDF) calls out the need to implement the ability to streamline the collection and sharing of digital identity data (Initiative 5). The Authoritative Attribute Exchange Services (AAES) is the architectural construct shown in the Roadmap as the mechanism that can implement this capability. This blog post provides a description of the capabilities needed in an AAES, and outlines a concrete method for implementing it; via deploying a Backend Attribute Exchange (BAE) infrastructure.

The AAES is a point of architectural abstraction between authoritative sources of identity information and the systems and applications that need that information.



At a high level, you can separate the functional requirements of an AAES into two buckets:

Authoritative Attribute Manager	Authoritative Attribute Distributer
Correlate attributes from various attribute sources De-conflict discrepancies across attribute sources Implement a data model for entity attributes Provide a consolidated view of the pieces of an entity gathered from multiple sources	Primary point of query for systems and applications Provide a customized and tailored view of data Support requests for attributes from both internal and external (to organization standing up the AAES) consumers

In order to meet these requirements, the implementation would need to provide capabilities "in the middle" such as Aggregation & Join, Mapping & Transformation, Routing & Load Balancing, Security & Audit and Local Storage (for caching) while providing standardized interfaces and connectors to applications and data sources.

A combination of a Virtual/Meta Directory Engine and a XML Security Gateway provides such a mix of capabilities:


The implementation of such an infrastructure is something we now have extensive experience with, from a combination of prototypes and proof-of-concepts, end-to-end pilots, as well as operational deployments of the various infrastructure elements. That is the reason why we chose these infrastructure elements as the foundational pieces for the Backend Attribute Exchange (BAE) infrastructure we are currently deploying:



As you can see above, there are also two supporting elements to the BAE infrastructure that we have deployed/are deploying; the BAE Metadata Service and the E-Government Trust Services (EGTS) Certificate Authority (CA). The BAE Metadata service will be the authoritative source of the metadata related to the BAE deployment and the EGTS CA will issue the Non-Person Entity (NPE) certificates that will be used to assure message level security across the members of the BAE "Attribute Federation".

In short, while the AAES is an abstract architectural construct, the infrastructure elements that make up the BAE are an example of a physical implementation of such a construct. It is being deployed in the near term to demonstrate operational capability with the goal of making it available as a shared service capability going forward.

RELATED POSTS

• What is new with the BAE Operational Deployment?
• Shared Services and Government as Attribute Service Provider

:- by Anil John

What is new with the BAE Operational Deployment?

GSA OGP, together with our partner PM-ISE, is moving out on the operational deployment of the FICAM Backend Attribute Exchange (BAE). The PM-ISE blog post "A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot" gives details about our primary use case. In this blog post, I am going to map those business and information sharing aspects to some of the technical details of the deployment.

The operational scenario looks like this:


In any such scenario, there are always three parties to the transaction. An Identity Provider, a Relying Party and an Attribute Provider.

"A law enforcement officer in Pennsylvania has an account on the Pennsylvania J-Net network, which supports many public safety, law enforcement, and state government agencies and mission communities. To obtain the J-Net account, the officer’s identity and status were vetted and various facts about identity, assignment, and qualifications were captured and maintained in the J-Net user database.

In the course of an investigation, the officer needs to access data on the RISS-Net system."

J-NET is the Identity Provider and RISS-Net Portal is the Relying Party.

"… both J-Net and RISS-Net are members of the National Information Exchange Federation (NIEF), RISS-Net can accept electronic credentials from J-Net once the officer logs into a J-Net account and is authenticated."

One of the primary reasons we are interested in this scenario (beyond the information sharing value of the deployed capability) is the existence of the NIEF Federation. NIEF already counts J-NET and RISS-NET as members. Which in turn means that there is an existing framework for collaboration and information sharing between them we can plug into, and enhance, with the BAE.

One of the critical technical benefits of this relationship, within the context of the BAE deployment, is that the Federation Identifier has been standardized across NIEF (gfipm:2.0:user:FederationId).

When we created the "SAML 2.0 Identifier and Protocol Profiles for BAE v2.0" (PDF), we deliberately separated out the profiling of the identifiers and the profiling of the protocols precisely so that we could "snap-in" new identifiers, without impacting the security of the protocol. We also put in some specific wording that allowed this flexibility; "It is expected that if credentials with [identifiers] other than what is profiled in this document are used in a BAE implementation, the Federation Operator governing that Community of Interest will define the profiles necessary for that credential type."

As part of this pilot, we will be defining an identifier profile for the NIEF Federation Identifier that will be used in the attribute query made to the BAE Attribute Service.

"RISS-Net has defined a policy for access to their information resources, which is expressed in terms of specific characteristics (“attributes”) of authenticated users. The RISS-Net policy requires that a user is certified as a “Law Enforcement Officer”, and has the necessary 28CFRPart 23 training."

The key to keep in mind is that the existing NIEF SAML Federation and the supporting information sharing framework already allows J-NET to assert the "Law Enforcement Officer" (LEO) attributes for their members when they go to access the RISS-Net Portal.

"… although the officer was trained on 28CFRPart23 in a course offered online by the Bureau of Justice Assistance (BJA), this fact is not part of the officer’s J-Net’s record (28CFRPart23 training status is not one of the facts gathered in their vetting process). Thus J-Net cannot provide all the credentials required by RISS-Net for access to the needed data."

And this is the critical value add for this pilot! There is additional information locked up within RISS-Net that can only be accessed if the 28CFRPart23 attribute is provided. J-Net is not able to assert this, but BJA as the authoritative attribute source can. And we are utilizing the BAE Shared Service Infrastructure deployed at GSA to provide them the capability to do so.

An item that we are still exploring is if the information that is available from the NIEF Federation Identifier as well as the J-NET Attribute Assertion gives enough information such that we can uniquely identify an existing record of a trained LEO at BJA. This is still an open question and is critical in making this work.

As you may have noted, I keep calling the deployment of the BAE Infrastructure at GSA a "Shared Service Infrastructure". That is a deliberate choice of words and I wil expand on that in the future, especially given that this is not our only pilot use case for the BAE deployment!

RELATED POSTS

• From AAES to BAE - Implementing Collection and Sharing of Identity Data
• PM-ISE: A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot
• Shared Services and Government as Attribute Service Provider
• PM-ISE: Advancing Identity Access Management (IdAM) with a Pilot Project in Pennsylvania

:- by Anil John

How the US Federal Government Participates in the NSTIC IDESG

The National Strategy for Trusted Identities in Cyberspace (NSTIC) Identity Ecosystem Steering Group (IDESG) has been launched and represents the formal handing of the baton to the private sector to lead the crafting of an Identity Ecosystem that can replace passwords, allow individuals to prove online that they are who they claim to be, and enhance privacy.

Congratulations to Jeremy Grant and the NSTIC National Program Office on their hard work in reaching this important milestone.

The Management Council of the IDESG is composed of Officers and Delegates from the various Stakeholder Groups. The US Federal Government is but one of the Stakeholders, and FICAM's own Deborah Gallagher has been elected as the US Federal Government's Delegate to the IDESG Management Council. She will be coordinating and bringing the US Federal Government's perspective to the IDESG.

On the FICAM side of the house, we are sometimes asked what our relationship to NSTIC is. The answer is rather simple; FICAM is the US Federal Government's implementation of the NSTIC Vision and Principles. As such, our focus is to assure the security and privacy of Government to Citizen (G2C), Government to Business (G2B) and Government to Government (G2G) digital interactions and services.

RELATED INFO

• NSTIC Identity Ecosystem Steering Group (IDESG)
• Identity Ecosystem Steering Group Plenary Groups
• Identity Ecosystem Steering Group Management Council
• National Strategy for Trusted Identities in Cyberspace (PDF)

:- by Anil John

What is new in the FICAM Trust Framework Provider Adoption Process?

The FICAM Trust Framework Provider Adoption Process (TFPAP) is the mechanism used by the Government to leverage industry-based credentials, that citizens already have, for use at Government web sites.

The current version of the Trust Framework Provider Adoption Process (PDF) was finalized in 2009. Since that time there has been great progress in E-Government activities, such as the launching of the National Strategy for Trusted Identities in Cyberspace (NSTIC) and the decision to move out on the FCCX initiative.

Input from Agencies that desire to deliver higher value Government to Citizen services combined with the increasing maturity and practical experience around credential and identity proofing offerings for higher Levels of Assurance are factors that affect this process.

To assure that the TFPAP is keeping pace with policy, technology and process advancements, we are starting the work needed to update the Trust Framework Provider Adoption Process. Some of the items we expect to address as part of this update include:

• Bringing all externally issued credentials from LOA 1 to 4, both non-PKI and PKI (i.e. PIV-I and Medium/HW credentials), under the TFPAP so that there is a consistent policy and guidance about how Agencies can best utilize these externally issued credentials. 
• Privacy Guidance, which was separately developed by the FICAM will be updated and integrated directly into the new TFPAP.
• Exploring how best to bring the TFPAP to bear on the Identity Provider / Attribute Provider / Relying Party aspects individually, and together.
• Integrating a robust and ongoing Test and Evaluation program into the TFPAP
• More...

Ultimately we are looking to make the TFPAP a more agile process and will be working with multiple stakeholders including, and especially, our existing approved Trust Framework Providers. The goal, as always, is to assure that we meet the needs of both Citizens and Agencies that seek to leverage these externally issued credentials.

RELATED POSTS

• FICAM Trust Framework Solutions - A Primer
• GSA OGP Announces an Industry Day on Federal Federated Identity Solutions

:- by Anil John

RFI/RFP Language for Federation Solutions and Identity Proofing Solutions

As noted in my earlier blog post "Comply with Requirements Quickly and Easily with RFI and RFP Templates", FICAM is working to make it easier for Agencies to align with OMB/NIST/FICAM policies. Given below is recommended language that aligns with policy for incorporation into Agency RFIs and RPFs.  The language covers both identity federation solutions, when the Agency is acting as a relying party, as well as identity proofing solutions.

Identity Federation Solution for Agency as Relying Party

• The solution shall support all currently approved FICAM Protocol Profiles, as found on IDManagement.gov, for browser based SSO (OpenID 2.0 and SAML 2.0 required; IMI 1.0 support is optional)
• The solution shall support newly approved FICAM Protocol profiles, as found on IDManagement.gov, within [90 days] of final approval by the ICAMSC
• The solution shall be capable of supporting all FICAM Adopted Trust Framework Provider Approved Credential Providers
• The solution shall be capable of supporting PIV (for Government-to-Government use cases) and PIV-I Authentication. This support must include Trust Path Discovery and Trust Path Validation functionality
• If the solution implements a SAML 2.0 Attribute Query/Response mechanism, it shall support the FICAM SAML 2.0 Identifier and Protocol Profiles for BAE v2.0 and the associated FICAM SAML 2.0 Metadata Profile for BAE v2.0
• The solution shall, at a minimum, support the following protocols and assertion formats for communication between itself and the relying party Agency application:
• Protocols: HTTP(S), SAML 2.0
• Assertion Formats: SAML 2.0, XML, JSON

Details: A federation solution is typically integrated with an Agency web application, and needs to support both non-government issued approved credentials as well as government issued credentials. Government issued credentials in this case are Agency issued PIV Cards and approved non-government credentials such as PIV-I and those that are governed by the FICAM Trust Framework Solutions Process.

Identity Proofing Service

• MUST have an identity proofing service capable of implementing [remote and/or in-person] identity proofing processes at [OMB-O4-04 LOA Level(s) here] per NIST SP 800-63-1

Details: NIST SP 800-63-1(PDF) is the authoritative document that provides information on the technical controls and approaches that an Agency must use for remote as well as in-person identity proofing requirements from LOA 1-4. Currently, FICAM does not have a certification process for a stand-alone identity proofing capability; current FICAM certification, via the Trust Framework Adoption Process, applies to a combined identity proofing-credential issuance solution. As such the requirements levied on an Identity Proofing service are based on the foundational requirements that all US Government Agencies must follow in complying with NIST Guidance.

Do keep in mind the following:

• The focus above is on the technical bits-n-bytes
• The above is just a starting point; Agencies are free to modify and add on other requirements as needed
• The above is subject to change based on new and/or updated policies

RELATED POSTS

• Comply with Requirements Quickly and Easily with RFI and RFP Templates
• FICAM Trust Framework Solutions - A Primer
• Shared Services and Government as Attribute Service Provider

:- by Anil John