tag:blogger.com,1999:blog-51486857134658056632017-06-06T23:25:57.956-04:00IDMGOV InfoU.S. Federal Identity, Credential and Access Management (FICAM) ProgramAnil Johnnoreply@blogger.comBlogger44125tag:blogger.com,1999:blog-5148685713465805663.post-31555171299378617172014-03-31T07:17:00.001-04:002014-04-29T06:48:56.494-04:00FICAM TFS TEM on Identity Resolution Needs for Online Service DeliveryThe <a href="http://www.idmanagement.gov/trust-framework-solutions">FICAM Trust Framework Solutions (TFS) Program</a> is convening public and private sector experts in identity proofing, identity resolution and privacy for an <b>Identity Resolution Needs for Online Service Delivery </b>Technical Exchange Meeting (TEM) on 5/1/14 from 9:00 AM - 5:00 PM EST in Washington, DC.<br /><br /><u>REGISTRATION</u><br /><br />Save the 5/1/14 date! In-person attendance and early registration (due to limited space) are recommended.<br /><br /><div style="text-align: center;"><span style="background-color: white; font-size: large;"><b><strike>Register Now!</strike></b></span></div><br /><div style="text-align: center;">Registration is now closed for this event!</div><br />Event Location: GSA, 1800 F St NW, Washington, DC 20405<br /><br />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.<br /><br />Questions? Please contact the FICAM TFS Program at <a href="mailto:TFS.EAO@gsa.gov">TFS.EAO@gsa.gov</a><br /><br /><u>BACKGROUND</u><br /><br />Identity attributes that are used to uniquely distinguish between individuals (versus describing individuals) are referred to as identifiers. <b>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</b>.<br /><br />Within the <b>context of enabling high value and sensitive online government services to citizens and businesses</b>, the ability to uniquely resolve the identity of an individual is critical to delivering government benefits, entitlements and services.<br /><br />As part of the <a href="http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html">recent update to FICAM TFS</a>, we recognized the Agency need for standardized approaches to identity resolution in our <a href="http://info.idmanagement.gov/2014/03/ficam-tfs-approval-process.html">Approval process</a> for <a href="http://info.idmanagement.gov/2013/12/ficam-tfs-component-identity-services.html">Credential Service Providers (CSPs) and Identity Managers (IMs)</a>.<br /><br />The study done by the NASPO IDPV Project, "<i>Establishment of Core Identity Attribute Sets & Supplemental Identity Attributes – Report of the IDPV Identity Resolution Project</i> (February 17, 2014)" is currently being used as an <b>industry based starting point </b>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.<br /><br /><u>TEM FOCUS</u><br /><br />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:<br /><ul><li>Articulate the identity federation needs of government agencies as it relates to identity resolution that balances identity assurance, privacy respecting approaches and cost-effectiveness</li><li>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</li><li>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</li></ul><u><br /></u><u>REQUEST FOR DISCUSSION TOPICS and STUDIES</u><br /><br />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 <a href="mailto:TFS.EAO@gsa.gov">TFS.EAO@gsa.gov</a> by COB 4/16/14 with your proposed discussion topic.<br /><br /><br /><u>DRAFT AGENDA for 05/01/2014</u><br /><br />09:00 AM - 09:30 AM Attendee Check-In<br />09:30 AM - 10:10 AM Welcome & TEM Overview/Goals/Level Set<br /><br />10:15 AM - 11:10 AM Agency Viewpoint Panel on Identity Resolution + Privacy<br /><i>[CMS, DHS, GSA, NIST, SSA, State Dept - Moderated by NIST]</i><br />11:15 AM - 11:45 AM Audience Discussion / Q&A<br /><br />11:45 AM - 01:00 PM LUNCH (On your own) & NETWORKING<br /><br />01:00 PM - 01:55 PM Industry Viewpoint Panel on Identity Resolution + Privacy<br /><i>[CertiPath, Experian, </i><i>ID/DataWeb, </i><i>LexisNexis, SecureKey, </i><i>Socure, </i><i>Symantec - Moderated by NIST</i><i>]</i><br />02:00 PM - 02:30 PM Audience Discussion / Q&A<br /><br />02:30 PM - 02:45 PM BREAK<br /><br />02:45 PM - 03:40 PM Joint Panel on Business Models / Cost / Innovation<br />[<i>Agency & Industry Panelists - Moderated by Kantara Initiative</i>]<br />03:45 PM - 04:15 PM Audience Discussion and Q&A<br /><br />04:15 PM - Event Wrap-up<br /><br />Sign up for our notification list @ <a href="http://www.idmanagement.gov/trust-framework-solutions">http://www.idmanagement.gov/trust-framework-solutions</a> to be kept updated on this and future FICAM TFS news, events and announcements.<br /><br /><br /><small> :- by Anil John<br />:- Program Manager, FICAM Trust Framework Solutions<br /></small>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-66657900893247707172014-03-28T13:31:00.001-04:002014-03-28T13:31:55.794-04:00ICAM Information Sharing Day and Vendor Expo - Spring 2014<div class="p1">We are pleased to announce that attendee registration is now open for the Spring 2014 ICAM Information Sharing Day and Vendor Expo. </div><br /><div class="p1">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.</div><br /><div class="p1">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. </div><br /><div class="p1">The theme of this year’s ICAM Day will focus on <b>Leveraging ICAM to Address Cybersecurity Threats,</b> 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. </div><br /><div class="p1">This event is open to government employees, contractors, and industry representatives (e.g., vendors).</div><br /><div class="p1">Space is limited and early registration is recommended. Online registration at <a href="http://www.gsa.gov/portal/content/188995">http://www.gsa.gov/portal/content/188995</a></div><br />:- Deb Gallagher, Paul Grant & Leo Scanlon<br />:- ICAMSC Co-ChairsAnil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-88163732056038381682014-03-21T11:07:00.001-04:002014-03-22T14:20:12.058-04:00HOW-TO: Become a FICAM TFS Approved Identity ServiceThe <a href="http://www.idmanagement.gov/trust-framework-solutions">FICAM Trust Framework Solutions (TFS) Program</a> is focused on enabling and supporting the security, privacy and interoperability requirements of Government to Citizen (G2C) and Government to Business (G2B) online services.<br /><br />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 <a href="http://info.idmanagement.gov/2013/12/ficam-tfs-component-identity-services.html">Identity Services</a> at assurance levels 2 and 3:<br /><br /><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"></div><br /><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-BexpgY_PJyk/UyxRPhXG-8I/AAAAAAAAAq4/fGTjIdCGP_c/s1600/FICAM_TFS_Approval_Process.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-BexpgY_PJyk/UyxRPhXG-8I/AAAAAAAAAq4/fGTjIdCGP_c/s1600/FICAM_TFS_Approval_Process.png" height="480" width="640" /></a></div><br /><br /><br />Step 1 in the above process can be initiated by contacting the FICAM TFS Program @ <a href="mailto:TFS.EAO@gsa.gov">TFS.EAO@gsa.gov</a><br /><br />A complete overview of the program and of the end-to-end approval processes can be found in the "<a href="http://www.idmanagement.gov/documents/trust-framework-solutions-overview">FICAM Trust Framework Solutions Overview</a>" and "<a href="http://www.idmanagement.gov/documents/authority-offer-services-atos-ficam-tfs-approved-identity-services">Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services</a>" documents which also has information on:<br /><ul><li>Streamlined level 1 approval process</li><li>Fast-track approval process for Financial Institutions required to implement a Customer Identification Program by Government regulators</li><li>High assurance approval process for PKI/Level 4 identity services that leverage existing Federal PKI Policy Authority processes</li></ul><br /><b>RELATED INFORMATION</b><br /><ul><li><a href="http://www.idmanagement.gov/trust-framework-solutions">FICAM Trust Framework Solutions Program</a></li><li><a href="http://info.idmanagement.gov/2013/12/ficam-tfs-component-identity-services.html">FICAM TFS Component Identity Services Terminology</a></li><li><a href="http://www.idmanagement.gov/approved-identity-services">FICAM TFS Approved Identity Services</a></li></ul><br /><br /><small>:- by Anil John<br />:- Program Manager, FICAM Trust Framework Solutions</small>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-21236483715788774192013-12-21T22:05:00.000-05:002014-02-05T17:37:51.483-05:00FICAM TFS Component Identity Services TerminologyAs part of a recent update, the concept of component identity services was incorporated into the <a href="http://info.idmanagement.gov/2013/11/ficam-trust-framework-solutions-tfs.html">FICAM Trust Framework Solutions (TFS)</a>. The component identity service model "<b>separates the functions of authentication and attribute providers</b>". <br /><br />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:<br /><ul><li>Vendors have focused their offerings according to their core strengths, which leads to improved quality of service for agency Relying Parties.</li><li>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.</li></ul>The model, shown below, utilizes the following OMB and NIST terminology:<br /><ul><li><b>Token</b>: Something that an individual possesses and controls that is used to authenticate the individual</li><ul><li>Tokens are possessed by an individual and controlled through one or more of the traditional authentication factors (something you know, have, or are)</li></ul><li><b>Identity</b>: A set of attributes that uniquely describe an individual within a given context</li><li><b>Credential</b>: An object or data structure that authoritatively binds an identity to a token possessed and controlled by an individual</li></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://1.bp.blogspot.com/-rU-INxqJ5NM/UvK8abam1iI/AAAAAAAAApQ/U6wNTnKTzjI/s1600/ficam-tfs-component-services.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://1.bp.blogspot.com/-rU-INxqJ5NM/UvK8abam1iI/AAAAAAAAApQ/U6wNTnKTzjI/s1600/ficam-tfs-component-services.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><i>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.</i><br /><br />The value of the model lies in the flexibility possible in combining the various functions as part of an industry service offering.<br /><br />Within the framework of the FICAM TFS Program, the following three combinations are recognized:<br /><br />A <b>Credential Service Provider,</b> which offers:<br /><ul><li>Token Management Services</li><li>Authentication Services</li><li>Identity Proofing Services</li><li>Attribute Validation Services</li></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-zBjcReIM5L8/UvK8cg6DJyI/AAAAAAAAApY/e6poeSPjSiA/s1600/ficam-tfs-csp.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-zBjcReIM5L8/UvK8cg6DJyI/AAAAAAAAApY/e6poeSPjSiA/s1600/ficam-tfs-csp.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><br />A <b>Token Manager</b>, which offers:<br /><ul><li>Token Management Services</li><li>Authentication Services </li></ul><div class="separator" style="clear: both; text-align: center;"><a href="http://4.bp.blogspot.com/-pQQIiv8d6D8/UvK8foqH-oI/AAAAAAAAApo/BAvmKYLDwwQ/s1600/ficam-tfs-tm.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://4.bp.blogspot.com/-pQQIiv8d6D8/UvK8foqH-oI/AAAAAAAAApo/BAvmKYLDwwQ/s1600/ficam-tfs-tm.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br /><br /><br />An <b>Identity Manager</b>, which offers:<br /><ul><li>Identity Proofing Services</li><li>Attribute Validation Services</li></ul><div class="separator" style="clear: both; text-align: center;"></div><div class="separator" style="clear: both; text-align: center;"><a href="http://3.bp.blogspot.com/-y699lIObzKk/UvK8d_Q3BLI/AAAAAAAAApg/77EESTDINSY/s1600/ficam-tfs-im.png" imageanchor="1" style="margin-left: 1em; margin-right: 1em;"><img border="0" src="http://3.bp.blogspot.com/-y699lIObzKk/UvK8d_Q3BLI/AAAAAAAAApg/77EESTDINSY/s1600/ficam-tfs-im.png" /></a></div><div class="separator" style="clear: both; text-align: center;"><br /></div><br />It should be noted that in all three cases, consent services are implementation specific and driven by policy.<br /><br />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.<br /><br /><small> :- by Anil John<br /></small>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-34743036921321807302013-11-13T21:43:00.002-05:002014-03-14T11:43:16.818-04:00FICAM Trust Framework Solutions (TFS) Program - UpdatedThe <strong>FICAM Trust Framework Solutions (TFS) is the federated identity framework for the U.S. federal government</strong>. It includes guidance, processes and supporting infrastructure to enable secure and streamlined citizen and business facing online service delivery.<br /><div class="separator" style="clear: both; text-align: center;"><img border="0" src="http://1.bp.blogspot.com/-bl3e6M90Tog/UvjoTaKCy9I/AAAAAAAAAqA/H9kyf4igM5w/s1600/ficam-tfs-overview.png" /></div><br />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.<br /><br />The <a href="http://www.idmanagement.gov/documents/trust-framework-solutions-overview"><b><i>FICAM Trust Framework Solutions Overview</i></b></a> provides a holistic overview of the FICAM TFS Program<br /><ul><li>Description of the components that make up the TFS Program</li><li>The TFS role in supporting Government-wide policy and National Strategy implementations</li><li>TFS and its implementation by Government Agencies</li><li>TFS fast-track process for Financial Institutions required to implement a Customer Identification Program by Government regulators </li><li>Relationship to the FICAM Testing Program for on-premise vendor solutions that implement FICAM protocol profiles </li></ul><div><br />The components of the FICAM TFS Program are:</div><ul><li>The<em> <a href="http://www.idmanagement.gov/documents/trust-framework-provider-adoption-process-tfpap-all-levels-assurance"><strong>Trust Framework Provider Adoption Process for All Levels of Assurance</strong></a></em> describes the process by which the TFS Program evaluates and adopts commercial Trust Frameworks for use by the U.S. federal government</li><ul><li>Overview of the Trust Framework Adoption Process</li><li>Incorporation of the privacy trust criteria into the Trust Framework adoption process</li><li>Updated trust criteria to incorporate NIST SP-800-63-2</li><li>Streamlined LOA 1 Trust Criteria</li><li>Introduction of ongoing verification as an OPTIONAL trust criteria</li><li>Support for Component Identity Services, and associated standardized terminology</li><li>TFS Program's relationship to entities (CSPs etc.) that are assessed and evaluated by an adopted Trust Framework Provider<br /> </li></ul><li>The<em> <a href="http://www.idmanagement.gov/documents/authority-offer-services-atos-ficam-tfs-approved-identity-services"><strong>Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services</strong></a></em><strong> </strong>makes explicit the requirements that identity services need to satisfy in order to offer their services to the U.S. federal government</li><ul><li>Clarification of approval decision authority of the FICAM TFS Program</li><li>Explicit testing and verification of service interfaces to assure conformance to approved protocols and profiles</li><li>Requirement to implement tested interfaces by the solution provider when offering the service to Government</li><li>Standards based attribute requirements to enable identity resolution by Government relying parties at LOA 2 and greater<br /> </li></ul><li>The<strong> <a href="http://www.idmanagement.gov/documents/identity-scheme-and-protocol-profile-adoption-process"><em>Identity Scheme and Protocol Profile Adoption Process</em></a> </strong>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.</li><ul><li>Updated to allow the flexibility for Government to adopt protocol profiles created by industry, provided it meets Government needs for security, privacy and interoperability</li><li>Standardized assurance level URIs for use in protocol profiles<br /> </li></ul><li>The <strong><a href="http://www.idmanagement.gov/documents/relying-party-guidance-accepting-externally-issued-credentials" style="font-style: italic;">Relying Party Guidance for Accepting Externally Issued Credentials</a> </strong>provides guidance to Agencies on leveraging federated identity technologies to accept externally issued credentials<br /> </li><li>The <a href="http://www.idmanagement.gov/documents/egca-egts-certificate-application-and-issuance-process"><em><strong>E-Governance Trust Services Certificate Authority</strong></em></a> provides a certificate issuance capability that supports the federated identity use cases of Agencies that require endpoint and message level protections<br /> </li><li>The <strong><em>E-Governance Trust Services Metadata Services (EGTS Metadata Services), </em></strong>once implemented and made available, provides a trusted mechanism for the collection and distribution of metadata to enable identity federation capabilities</li></ul><div><strike>All of the above documents, except for the <em>Relying Party Guidance </em>and the<em> EGTS CA Concept of Operations,</em> are currently in DRAFT status while we seek feedback from our Public and Private sector stakeholders.</strike><br /><strike><br /></strike></div><div></div><div><strike>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 <a href="http://www.idecosystem.org/group/trust-framework-and-trustmark-committee">IDESG Trust Framework and Trustmark (TFTM) Committee.</a></strike><br /><br />UPDATE 2/7/2014: The updates to the FICAM TFS have been finalized and are now available.<br /><br /></div><div></div><div><strong>RELATED INFO</strong></div><div><ul><li><a href="http://www.idmanagement.gov/documents/trust-framework-solutions-overview">FICAM Trust Framework Solutions Overview</a></li><li><a href="http://www.idmanagement.gov/documents/trust-framework-provider-adoption-process-tfpap-all-levels-assurance">Trust Framework Provider Adoption Process for All Levels of Assurance</a></li><li><a href="http://www.idmanagement.gov/documents/authority-offer-services-atos-ficam-tfs-approved-identity-services">Authority To Offer Services (ATOS) for FICAM TFS Approved Identity Services</a></li><li><a href="http://www.idmanagement.gov/documents/identity-scheme-and-protocol-profile-adoption-process">Identity Scheme and Protocol Profile Adoption Process</a></li><li><a href="http://www.idmanagement.gov/documents/relying-party-guidance-accepting-externally-issued-credentials">Relying Party Guidance for Accepting Externally Issued Credentials</a></li><li><a href="http://www.idmanagement.gov/documents/egca-egts-certificate-application-and-issuance-process">E-Governance Trust Services Certificate Authority</a></li></ul></div><div></div><br />:- by Anil John<br />:- Program Manager, FICAM Trust Framework SolutionsAnil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-61609989705690758532013-06-03T16:12:00.001-04:002013-06-25T19:07:45.903-04:00Federal ICAM Information Sharing Day and Vendor Expo <p>The Federal ICAM Information Sharing Day and Vendor Expo will take place on <strong>Tuesday, June 18, 2013 from 8:00 a.m. to 4:00 p.m.</strong><br /> <strong><br /></strong> This event will consist of <strong>presentations, panel discussions, and breakout sessions</strong> 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.<br /> <br /> This free event is open to government employees, contractors, and industry representatives (e.g., vendors).<br /> <strong><br /></strong> <strong>LOGISTICS/VENUE INFORMATION </strong><br /> <br /> 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:</p><blockquote><strong>GSA One Constitution Square Building<br /> 1275 First Street NE, Washington</strong></blockquote><p><strong>REGISTRATION INFORMATION</strong><br /> <br /> Those attending ICAM Information Day and Vendor Expo should register at the following site: <a href="http://www.gsa.gov/ICAMexpo">http://www.gsa.gov/ICAMexpo</a><br /> <br /> Special Information for Vendor Registration<br /> <br /> 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.<br /> <strong><br /></strong> <strong>AGENDA</strong><br /> <br /> Please note that the agenda is subject to change.</p><div align="center"><table style="width: 80%px;" border="1" cellspacing="0" cellpadding="5" align="center"><thead><tr><td width="23%"><div align="center"><strong>Timeframe</strong></div></td><td width="51%"><div align="center"><strong>Description</strong></div></td><td width="25%"><div align="center"><strong>Speaker</strong></div></td></tr></thead><tbody><tr><td width="23%"><div align="center"><strong>8:00 – 9:00</strong></div></td><td valign="top" width="51%"><div class="tablebodytext">Registration</div></td><td valign="top" width="25%"><div class="tablebodytext"> </div></td></tr><tr><td width="23%"><div align="center"><strong>9:00 – 9:10</strong></div></td><td valign="top" width="51%"><div class="tablebodytext"><a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Opening%20Remarks%20-%20ICAMSC.pptx">Welcome and Opening Remarks</a></div></td><td valign="top" width="25%"><div class="tablebodytext">Deb Gallagher (GSA)<br /> Paul Grant (DoD)</div></td></tr><tr><td width="23%"><div align="center"><strong>9:10 – 9:30</strong></div></td><td valign="top" width="51%"><div class="tablebodytext"><a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20FICAM%20Testing%20Presentation.pptx">FIPS 201/FICAM Testing Program Update</a></div></td><td valign="top" width="25%"><div class="tablebodytext">Chi Hickey (GSA)</div></td></tr><tr><td width="23%"><div align="center"><strong>9:30 – 10:30</strong></div></td><td valign="top" width="51%"><a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Attribute%20Exchange%20Panel.pptx"><strong>Panel Discussion: Attribute Exchange and Information Sharing in Action</strong></a><br /> 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.</td><td valign="top" width="25%">Anil John (GSA), Moderator<br /><ul><li>David Coxe (ID DataWeb, Inc.)</li><li>Dieter Schuller (Radiant Logic)</li><li>Nathaniel (Ted) Sobel (DHS)</li><li>John F. Wandelt (GTRI)</li><li>Martin Smith (PM-ISE)</li></ul></td></tr><tr><td width="23%"><div align="center"><strong>10:30 – 11:30</strong></div></td><td valign="top" width="51%"><a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Externalizing%20Authentication%20Panel.pptx"><strong>Panel Discussion: Externalizing Authentication</strong></a><br /> 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.</td><td valign="top" width="25%">Anil John (GSA), Moderator<br /><ul><li>FCCX Team</li><li>MAX.GOV Team</li></ul></td></tr><tr><td width="23%"><div align="center"><strong>11:30 – 12:30</strong></div></td><td colspan="2" valign="top" width="76%"><div class="tablebodytext">Lunch break (lunch not provided)</div></td></tr><tr><td width="23%"><div align="center"><strong>12:30 – 4:00</strong></div></td><td colspan="2" valign="top" width="76%"><div class="tablebodytext">Vendor Expo</div></td></tr><tr><td width="23%"><div align="center"><strong>12:30 – 1:15</strong></div></td><td colspan="2" valign="top" width="76%"><div class="tablebodytext"><strong>Breakout Session 1 </strong></div><div class="tablebodytext"><strong><br /></strong></div><strong>FICAM Procurement [Government Only. PIV Required for Entrance]</strong><br /> <strong></strong>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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Mobility%20Breakout%20Session.PPTX"><strong>Driving Mobility Forward with ICAM</strong></a><br /> 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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Enterprise%20PACS%20Best%20Practices%20Breakout%20Session.pptx"><strong>Enterprise PACS Solution Best Practices</strong></a><br /> 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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Value%20of%20ICAM%20Breakout%20Session%20FINA....pptx"><strong>Realizing the Value of ICAM</strong></a><br /> 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.</td></tr><tr><td width="23%"><div align="center"><strong>1:20 – 2:05</strong></div></td><td colspan="2" valign="top" width="76%"><div class="tablebodytext"><strong>Breakout Session 2 </strong></div><div class="tablebodytext"><strong><br /></strong></div><strong>FICAM Procurement [<strong>Government Only. PIV Required for Entrance</strong>]</strong><br /> <strong></strong>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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Mobility%20Breakout%20Session.PPTX"><strong>Driving Mobility Forward with ICAM</strong></a><br /> 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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Enterprise%20PACS%20Best%20Practices%20Breakout%20Session.pptx"><strong>Enterprise PACS Solution Best Practices</strong></a><br /> 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.<br /> <br /> <a href="http://idmanagement.gov/sites/default/files/documents/ICAM%20Day%20Value%20of%20ICAM%20Breakout%20Session%20FINA....pptx"><strong>Realizing the Value of ICAM</strong></a><br /> 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.</td></tr><tr><td width="23%"><div align="center"><strong>2:10 – 2:35</strong></div></td><td valign="top" width="51%">Accelerating the implementation timeline and reducing the cost of PIV in application by using Cloud services</td><td valign="top" width="25%"><ul><li>Xceedium</li><li>Amazon Web Services</li></ul></td></tr><tr><td width="23%"><div align="center"><strong>2:35 – 3:35</strong></div></td><td valign="top" width="51%"><strong>Panel Discussion: Tackling an Evolving Mobile Environment</strong><br /> 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.</td><td valign="top" width="25%"><div class="tablebodytext">Donna Dodson (NIST), Moderator<br /><ul><li>John Hickey (DOD/DISA)</li><li>Tom McCarty (DHS)</li><li>Adam Zeimet (USDA)</li></ul></div></td></tr><tr><td width="23%"><div align="center"><strong>3:35 – 3:55</strong></div></td><td valign="top" width="51%"><div class="tablebodytext">OMB ICAM Update <br /><strong>[Government Only. PIV Required for Entrance]</strong></div></td><td valign="top" width="25%"><div class="tablebodytext">Carol Bales (OMB)</div></td></tr><tr><td width="23%"><div align="center"><strong>3:55 – 4:00</strong></div></td><td valign="top" width="51%"><div class="tablebodytext">Closing Remarks</div></td><td valign="top" width="25%"><div class="tablebodytext">Salomeh Ghorbani (GSA)</div></td></tr></tbody></table></div>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-76248019850140712932013-04-10T19:59:00.000-04:002013-08-09T11:16:10.022-04:00FICAM Trust Framework Solutions TFPAP Update v1.1.0The <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework">FICAM Trust Framework Solutions (TFS)</a> Trust Framework Provider Adoption Process (TFPAP) has been<a href="http://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_TFPAP_v1.1.0.pdf"> updated to v1.1.0</a> (PDF).<br /><img alt="TFS TFPAP v1 1 0" border="0" height="373" src="https://lh3.ggpht.com/-lEgCdijHjkc/UWX7hLhRIGI/AAAAAAAAAb4/uwL6IZtrQ-U/TFS_TFPAP_v1.1.0.png?imgmax=800" style="border: 1px; float: right;" title="TFS_TFPAP_v1.1.0.png" width="300" /><br />This is a point update that does not change any of the existing TFP processes but instead:<br /><ul><li>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. </li><li>Incorporates the Trust Framework Solutions (TFS) "branding" under FICAM. </li></ul>The relevant text that acknowledges the existing processes is the following:<br /><blockquote><i>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.</i></blockquote><blockquote><i>The TFS is inclusive of externally issued PKI and non-PKI credentials at OMB Levels of Assurance 1, 2, 3 and 4:</i><br /><ul><li><i>For PKI based credentials the <b>TFS recognizes the Federal PKI Policy Authority (FPKIPA) as a TFS approved Trust Framework Provider</b> and will rely on its proven criteria and methodology for non-Federally issued PKI credentials. </i></li><li><i>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).</i></li></ul></blockquote>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:<br /><ol><li>Trust Framework Provider Adoption Process (TFPAP)</li><li>The Relying Party Guidance on Accepting Externally Issued Credentials (Currently under internal review)</li><li>FICAM TFS Trust Mark (Future)</li></ol><b>RELATED INFO</b><br /><ul><li><a href="http://www.idmanagement.gov/sites/default/files/documents/FICAM_TFS_TFPAP_v1.1.0.pdf">FICAM TFS Trust Framework Provider Adoption Process v1.1.0 (PDF)</a></li></ul><small>:- by Anil John</small>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-76188157096807540972012-11-19T08:14:00.001-05:002012-11-19T18:18:48.106-05:00Federal ICAM Information Sharing Day and Vendor Expo<p><strong>The Federal Identity, Credential and Access Management Subcommittee Announces the ICAM Information Sharing Day and Vendor Expo</strong></p><p>On November 27<sup>th</sup>, 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.</p><p><strong>LOGISTICS/VENUE INFORMATION </strong></p><p>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<sup>th</sup> – 30<sup>th</sup> at the following location:</p><blockquote><p><strong>Washington Convention Center<br /> 801 Mount Vernon Place Northwest, Washington, DC 20001</strong></p></blockquote><p>There will be no fee for federal employees and contractors with PIV attending the ICAM Information Day event.</p><p><strong>REGISTRATION INFORMATION</strong></p><p>Those attending ICAM Information Day and Vendor Expo should register at the following site: <a href="http://www.GovSmartID.com">www.GovSmartID.com</a></p><p><strong>AGENDA</strong></p><p>Please note that the agenda is subject to change.</p><div align="center"><table width="80%" border="1" cellspacing="0" cellpadding="5" align="center"><thead><tr><td width="23%"><p align="center"><strong>Timeframe</strong></p></td><td width="51%"><p align="center"><strong>Description</strong></p></td><td width="25%"><p align="center"><strong>Speaker</strong></p></td></tr></thead><tbody><tr><td width="23%"><p align="center"><strong>9:00 – 9:15</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Welcome and Opening Remarks</p></td><td valign="top" width="25%"><p class="tablebodytext">Deb Gallagher (GSA) and/or Paul Grant (DoD)</p></td></tr><tr><td width="23%"><p align="center"><strong>9:15 – 10:00</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Keynote Address: Enabling CAC/PIV in a Mobile Government Workforce</p></td><td valign="top" width="25%"><p class="tablebodytext">Rob Carey (DoD)</p></td></tr><tr><td width="23%"><p align="center"><strong>10:00 – 12:00</strong></p></td><td colspan="2" valign="top" width="76%"><p class="tablebodytext">Opening of the Vendor Exhibits</p></td></tr><tr><td width="23%"><p align="center"><strong>12:00 – 12:30</strong></p></td><td colspan="2" valign="top" width="76%"><p class="tablebodytext">Lunch break (lunch not provided)</p></td></tr><tr><td width="23%"><p align="center"><strong>12:30 – 1:00</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Security Policy and Standards for Use of Mobile Devices on Federal Networks</p></td><td valign="top" width="25%"><p class="tablebodytext">Carol Bales (OMB)/ Donna Dodson (NIST)</p></td></tr><tr><td width="23%"><p align="center"><strong>1:00 – 1:30</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Expectation of PIV use with Logical Access Systems</p></td><td valign="top" width="25%"><p class="tablebodytext">Bill Erwin (DoD)</p></td></tr><tr><td width="23%"><p align="center"><strong>1:30 – 2:00</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Expectation of PIV use with Mobile Devices</p></td><td valign="top" width="25%"><p class="tablebodytext">Deb Gallagher (GSA)</p></td></tr><tr><td width="23%"><p align="center"><strong>2:00 – 2:30</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Expectation of PIV use with Physical Access Systems</p></td><td valign="top" width="25%"><p class="tablebodytext">Will Morrison (FAA)</p></td></tr><tr><td width="23%"><p align="center"><strong>2:30 – 3:00</strong></p></td><td colspan="2" valign="top" width="76%"><p class="tablebodytext">Afternoon Break (vendor exhibits will remain open)</p></td></tr><tr><td width="23%"><p align="center"><strong>3:00 – 3:15</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">FIPS 201-2 Status</p></td><td valign="top" width="25%"><p class="tablebodytext">Hilde Ferraiolo (NIST)</p></td></tr><tr><td width="23%"><p align="center"><strong>3:15 – 3:30</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Update on FY FISMA Metrics for PIV Use</p></td><td valign="top" width="25%"><p class="tablebodytext">Glen Lee (DOE)/ Rajeev Pillai ( GSA)</p></td></tr><tr><td width="23%"><p align="center"><strong>3:30 – 3:45</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Trust Framework Update</p></td><td valign="top" width="25%"><p class="tablebodytext">Anil John (GSA)</p></td></tr><tr><td width="23%"><p align="center"><strong>3:45 – 4:15</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Open Discussion</p></td><td valign="top" width="25%"><p class="tablebodytext">Deb Gallagher (GSA) and/or Paul Grant (DoD)</p></td></tr><tr><td width="23%"><p align="center"><strong>4:15 – 4:30</strong></p></td><td valign="top" width="51%"><p class="tablebodytext">Closing Remarks</p></td><td valign="top" width="25%"><p class="tablebodytext">Deb Gallagher (GSA) and/or Paul Grant (DoD)</p></td></tr></tbody></table></div>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-37765991283902559842012-10-29T16:00:00.000-04:002013-01-09T21:43:17.234-05:00Challenges in Operationalizing Privacy in Identity Federations - Part 3<p><a href="http://info.idmanagement.gov/2012/09/challenges-in-operationalizing-privacy.html">Part 1 of this series</a> discussed the data minimization principles of anonymity, unlinkability and unobservability and their relationship to identity federation. <a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html">Part 2 of this series</a> 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.<br /> <br /><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html">In the proxy architecture</a>, when a user arrives for the first time at the relying party (RP) after being authenticated by the IdP/CSP, the RP knows:</p><ol><li>A trusted IdP has authenticated the user, </li><li>The Level of Assurance (LOA) of the credential used, and </li><li>The Persistent Anonymous Identifier (PAI) associated with the credential of the authenticated user. </li></ol><p>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).<br /> <br /> The RP starts the <a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">user enrollment process</a> 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. <strong>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</strong>.<br /> <br /> The RP then initiates the attribute verification process:</p><ul><li>The request is made via the proxy to maintain the PAI to PPID mapping and the PPID to CID mapping</li><li>The <a href="http://info.idmanagement.gov/2012/10/how-to-implement-technical-aspects-of.html">request is for a MATCH/NOMATCH answer</a> and NOT a "Give me all the attributes you have collected during identity proofing"</li><li>The shared private data (e.g. Account #, Access Code, SSN etc.), <strong>which is ALREADY in the RP system</strong>, is NOT sent to the IdP/CSP</li></ul><p><img style="display: block; margin-left: auto; margin-right: auto;" title="PrivacyProxy_AX.png" src="http://lh4.ggpht.com/-b17EW2SB3wA/UIvteUYn1QI/AAAAAAAAAPw/rz4NARX4DnU/PrivacyProxy_AX.png?imgmax=800" alt="PrivacyProxy AX" width="600" height="415" border="0" /><br /> <br /> If the response that comes back from the IdP/CSP is positive, the RP:</p><ul><li>Uses the shared private piece of data to pull up the associated user record </li><li>Checks to see if the verified attributes returned match those in the user record</li><li>If they match, the RP links the PAI to the associated user record locator a.k.a. Program Identifier (PID)</li></ul><p>Critical points to note here are that the <strong>IdP still does not know which RP the user went to</strong>, the <strong>RP still does not know which IdP the user is coming from</strong>, but the <strong>Proxy now has visibility into the attributes flowing through it.</strong> 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 <strong>proxy does not collect, store or log the attribute values flowing <strong>through</strong> it</strong>.<br /> <br />We would be interested to hear about how this architecture can be improved or modified to enhance its privacy characteristics.<br /> <br /> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/06/how-to-verify-citizen-identity-easily.html">How to Verify Citizen Identity Easily and Effectively</a></li><li><a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">If You Don't Plan For User Enrollment Now, You'll Hate Federation Later</a></li><li><a href="http://info.idmanagement.gov/2012/09/challenges-in-operationalizing-privacy.html">Challenges in Operationalizing Privacy in Identity Federations</a></li><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html">Challenges in Operationalizing Privacy in Identity Federations - Part 2</a></li><li><a href="http://info.idmanagement.gov/2012/10/how-to-implement-technical-aspects-of.html">How To Implement the Technical Aspects of an Identity Oracle</a></li><li><a href="http://nat.sakimura.org/2012/10/21/mic-spp-2/">Nat Sakimura: Privacy Enhancement for Open Federated Identity/Access Management Platforms (PEOFIAMP) R&D Project</a></li></ul><p><br /><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-68985297920343437802012-10-22T07:00:00.000-04:002013-01-09T21:43:48.354-05:00What are FICAM Technical Profiles and Identity Schemes?<p>A critical technology underpinning of the <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Trust Framework Solutions</a> 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.<br /> <br /> 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.<br /> <br /> <img style="float: right;" title="FICAMProfileScheme.png" src="http://lh3.ggpht.com/-3yQbj95wmA8/UIGSA3xOAWI/AAAAAAAAAPg/RH1mWuHaIoU/FICAMProfileScheme.png?imgmax=800" alt="FICAM Profiles and Schemes" width="350" height="247" border="0" />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.<br /> <br /> This requires the standard to undergo a "Profiling" process that:</p><ul><li>DOES NOT change the standard in any way</li><li>DOES take into consideration security requirements of the federal government</li><li>DOES take into consideration privacy requirements of the federal government</li><li>Locks down the MUSTs, SHOULDs, SHOULD NOTs etc. in the specification language so that there is assured interoperability between profile implementations</li><li>Results in a "Test-able" product</li></ul><p>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 <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">"portable identity schemes"</a> which enabled the use of identity federation protocols to convey information for the purpose of authentication.<br /> <br /> The <a href="http://www.idmanagement.gov/documents/SAML20_Web_SSO_Profile.pdf">"FICAM Profile of SAML 2.0 for Web SSO (PDF)"</a> and the <a href="http://www.idmanagement.gov/documents/ICAM_OpenID20Profile.pdf">"FICAM OpenID 2.0 Profile (PDF)"</a> 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).<br /> <br /> 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 "<a href="http://www.idmanagement.gov/documents/BAE_v2_SAML2_Profile_Final_v1.0.0.pdf">SAML 2.0 Identifier and Protocol Profiles for BAE v2.0 (PDF)</a>" and "<a href="http://www.idmanagement.gov/documents/BAE_v2_SAML2_Metadata_Profile_Final_v1.0.0.pdf">SAML 2.0 Metadata Profile for BAE v2.0</a>" stand on their own and are not authentication related.<br /> <br /> We expect this to continue and expand in the future.<br /> <br /> 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.<br /> <br /> 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.<br /> <strong><br /></strong> <strong>RELATED INFORMATION</strong></p><ul><li><a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">FICAM Technical Profiles and Identity Schemes</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-31971574485659680382012-10-15T17:04:00.000-04:002013-01-09T21:44:22.170-05:00How To Implement the Technical Aspects of an Identity Oracle<p>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 <a href="http://info.idmanagement.gov/2012/09/from-aaes-to-bae-implementing.html">Backend Attribute Exchange (BAE)</a> Protocol Profile.<br /> <br /> The original definition of an "Identity Oracle" which was coined back in 2006 by Bob Blakley, the current <a href="http://www.idecosystem.org/">NSTIC IDESG</a> Plenary Chair, is:</p><ul><li>An organization which derives all of its profit from collection & use of your private information…</li><li>And therefore treats your information as an asset…</li><li>And therefore protects your information by answering questions (i.e. providing meta-identity information) based on your information without disclosing your information…</li><li>Thus keeping both the Relying Party and you happy, while making money.</li></ul><p>While that applies to commercial entities pretty well, let me tweak that a bit for the Government sector:</p><ul><li>An organization which is the authoritative source of some of your private information…</li><li>And is constrained by law and policy to safeguard your information…</li><li>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…</li><li>Thus keeping both You and the Relying Party happy, while enabling you to conduct safe, secure and privacy preserving online transactions</li></ul><p><img style="float: right;" title="IdentityOracle.png" src="http://lh5.ggpht.com/--sFXW1po2DA/UHisVX5TbtI/AAAAAAAAAPI/zCUDuBRZWOA/IdentityOracle.png?imgmax=800" alt="Identity Oracle" width="300" height="284" border="0" /><br /> A potential technical interaction between the three entities could be:</p><ol><li>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</li><li>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</li><li>The Relying Party asks the Identity Oracle “<strong>Am I allowed to offer service X to the Person with a token Y from You under condition Z?</strong>”.<strong> The Identity Oracle answers “Yes or No”</strong></li></ol><p>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.<br /> <br /> 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 <strong>"XACML 3.0 Attribute Verification Profile for BAE 2.0":</strong><br /> <strong><br /></strong> <img style="display: block; margin-left: auto; margin-right: auto;" title="BAE_XACML.png" src="http://lh3.ggpht.com/-_REMutcvmwc/UHisWFzyF5I/AAAAAAAAAPQ/fqp3_VGrJLQ/BAE_XACML.png?imgmax=800" alt="BAE XACML" width="599" height="246" border="0" /><br /> <br /> The intent of this effort will be to <a href="http://info.idmanagement.gov/2012/09/attributes-anytime-anywhere-extending.html">profile XACML 3.0 messages on the wire, not for authorization, but to enable the construction of a verification request and corresponding response</a>, 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.<br /> <strong><br /></strong> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/09/attributes-anytime-anywhere-extending.html">Attributes Anytime, Anywhere. Extending BAE to Support New Protocols</a></li><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy_29.html">Challenges in Operationalizing Privacy in Identity Federations - Part 3</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-49397299092237698012012-10-08T16:27:00.000-04:002013-01-09T21:44:52.778-05:00Challenges in Operationalizing Privacy in Identity Federations - Part 2<p>Federation implementations enabling <a href="http://info.idmanagement.gov/2012/09/challenges-in-operationalizing-privacy.html">privacy enhancing characteristics such as anonymity, unlinkability and unobservability</a> 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.<br /> <br /> The typical identity federation scenario with an externalized Identity/Credential Provider and a Relying Party looks something like this:<br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="BrokeredAuthN.png" src="http://lh5.ggpht.com/-6Z1X3isfSuA/UHM1kQxMhMI/AAAAAAAAAOY/jF8AFnWT43s/BrokeredAuthN.png?imgmax=800" alt="Brokered AuthN" width="599" height="313" border="0" /></p><ul><li>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</li><li>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 <a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">user enrollment process</a></li><li>The IdP knows about the RP the user is interacting with so there is no mitigation for the loss of unobservability</li></ul><p>If implementing this using SAML 2.0, this would be the classic SAML Web SSO Sequence Diagram with a persistent identifier for NameID:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="BrokeredAuthN_SAML.png" src="http://lh4.ggpht.com/-YbHAAbJEqfY/UHM1lCP0NCI/AAAAAAAAAOg/5-wWcH8ppR8/BrokeredAuthN_SAML.png?imgmax=800" alt="Brokered AuthN SAML" width="599" height="449" border="0" /><br /> <br /> 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:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="PrivacyProxy.png" src="http://lh5.ggpht.com/-B2J6Nm_AmGg/UHM1lsO3v4I/AAAAAAAAAOo/CdZ1mwBrRxo/PrivacyProxy.png?imgmax=800" alt="Privacy Proxy" width="599" height="333" border="0" /></p><ul><li>CID to PPID mapping is the same as before. Limits loss of anonymity and unlinkability</li><li>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. </li><li>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 </li><li>RP know that a trusted IdP authenticated the user and the associated LOA level but nothing more</li><li>RP manages the PAI to PID mapping</li><li>The proxy knows of the IdP and the RP but knows nothing other than the PPID and the PAI</li><li>Forensics requires coordination across IdP, Proxy and RP</li></ul><p>As an aside, I would like to acknowledge our colleagues at <a href="http://kantarainitiative.org/confluence/download/attachments/45059378/CA+-+CATS+IAS+V2.0_Deployment+Profile_Final+r7.2_en.pdf?version=1&modificationDate=1307414853000">TBS Canada for how they defined PAI and PID</a> (PDF); I saw no value in coming up another term to describe the same items, so decided to simply leverage their definitions.<br /> <br /> 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:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="PrivacyProxy_SAML.png" src="http://lh5.ggpht.com/-yeSGa0Px_rk/UHM1me00XnI/AAAAAAAAAOw/Mag87w6_ZRs/PrivacyProxy_SAML.png?imgmax=800" alt="Privacy Proxy SAML" width="600" height="448" border="0" /><br /> <br /> 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:</p><ul><li>How can the RP <a href="http://info.idmanagement.gov/2012/09/how-to-collect-and-deliver-attributes.html">gain access to the attributes</a> collected during the identity proofing stages by the IdP/CSP?</li><li>Can all or most of the privacy characteristics still survive when <a href="http://info.idmanagement.gov/2012/09/how-to-collect-and-deliver-attributes.html">attribute movement</a> comes into play for user enrollment?</li></ul><p>Any insights and lessons learned on working with this type of architecture would be appreciated.<br /> <br /> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/06/how-to-verify-citizen-identity-easily.html">How to Verify Citizen Identity Easily and Effectively</a></li><li><a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">If You Don't Plan For User Enrollment Now, You'll Hate Federation Later</a></li><li><a href="http://info.idmanagement.gov/2012/09/challenges-in-operationalizing-privacy.html">Challenges in Operationalizing Privacy in Identity Federations</a></li><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy_29.html">Challenges in Operationalizing Privacy in Identity Federations - Part 3</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-4829675843973354452012-09-30T16:05:00.001-04:002013-01-09T21:45:17.664-05:00Challenges in Operationalizing Privacy in Identity Federations<p>A critical part of the <strong>job of an identity/information management professional is to operationalize privacy in the systems they architect, build and deploy</strong>. 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.<br /> <br /> <img style="float: right;" title="FIPPs.png" src="http://lh3.ggpht.com/-Xfv99iF-d4I/UGikaBgWMNI/AAAAAAAAAOI/Idt-f6X8rYs/FIPPs.png?imgmax=800" alt="FIPPs" width="315" height="400" border="0" />NIST, in its <a href="http://csrc.nist.gov/publications/drafts/800-130/second-draft_sp-800-130_april-2012.pdf">DRAFT SP 800-130 "A Framework for Designing Cryptographic Key Management Systems" (PDF)</a> articulates the three privacy characteristics (Section 4.7) of <strong>Anonymity, Unlinkability and Unobservability</strong>:</p><blockquote><em>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.</em></blockquote><p>In his <a href="http://pomcor.com/2012/09/25/report-on-the-nist-cryptographic-key-management-workshop/">write-up of the NIST CKMS Workshop, Dr. Francisco Corella</a> had this to say as it relates to identity federation:</p><blockquote><em>"[...] 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.</em><br /> <em></em></blockquote><blockquote><em>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.<strong> Profiles of third-party login protocols approved for citizen login to government sites mitigate some of these drawbacks</strong> 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.</em><br /> <em></em></blockquote><blockquote><em>I believe that the Government should work to develop and promote authentication methods that eliminate passwords while preserving anonymity, unlinkability and unobservability."</em></blockquote><p>Agreed.<br /> <br /> 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 <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">FICAM Identity Schemes (i.e. Protocol Profiles for Authentication)</a> 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 <a href="http://info.idmanagement.gov/2012/07/gsa-announces-industry-day-on-federal.html">on our FCCX initiative, we are specifically calling out the issue of "panopticality"</a> as something that is critical for us to address.<br /> <br /> 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. <br /> <br /> 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 <strong>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</strong> so that Government can leverage and utilize them as part of delivering Citizen facing services.</p><p><strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy.html">Challenges in Operationalizing Privacy in Identity Federations - Part 2</a></li><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy_29.html">Challenges in Operationalizing Privacy in Identity Federations - Part 3</a></li></ul><p><br /> <small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-42881108496414919032012-09-23T14:33:00.001-04:002013-01-09T21:45:40.605-05:00How To Collect and Deliver Attributes to a Relying Party for User Enrollment<p>In order for <a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">user enrollment to work at a Relying Party (RP)</a> 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 <a href="http://info.idmanagement.gov/2012/06/how-to-verify-citizen-identity-easily.html">identity verification model</a> that is used. This blog post describes the steps and considerations regarding attribute movement for the purpose of user enrollment.<br /> <br /> The steps in this process, from the perspective of the RP, are:</p><ol><li>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</li><li>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</li><li>Determine who will collect, verify and bind the attributes to an identifier, and if the assurance level of that binding is acceptable</li><li>Determine the secure mechanism needed to move the attributes from the entity that collected them to the Relying Party</li></ol><p><strong>1. Determine the minimal set of attributes</strong></p><ul><li><img style="float: right;" title="RP_DataCollection.png" src="http://lh3.ggpht.com/-XvCfphtLN9c/UF9UD5hszqI/AAAAAAAAANs/kbXZ1eTe4iU/RP_DataCollection.png?imgmax=800" alt="RP DataCollection" width="375" height="232" border="0" />What is the minimum set of attributes needed to uniquely identify a person within a system?</li><li>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?</li></ul><p><strong><br /></strong> <strong>2. Implement PII Protection on collected attributes </strong></p><ul><li>Has a Privacy Impact Assessment been done that includes clear identification of the data needed and collected?</li><li>Do you have the authority to collect this information? How will you track and verify user consent?</li><li>Have you implemented technical and policy protections on PII information as required?</li></ul><p><strong><br /></strong> <strong>3. Who will collect and verify the attributes?</strong></p><ul><li>Will the attributes be collected and verified by an Identity/Credential Provider or a Registration/Identification Service?</li><li>Will the attributes be collected by the Relying Party and be verified directly or by leveraging a third party service?</li><li>Is the verification of attributes and the binding to an identity comply with <a href="http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf">NIST 800-63-1(PDF)</a> identity proofing requirements?</li><li>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? </li></ul><div><strong><br /></strong> <strong>4. How will you securely move the attributes?</strong></div><ul><li><img style="float: right;" title="RP_DataCollection_2.png.png" src="http://lh3.ggpht.com/-5tOK_jfRtjo/UF9UETgy7OI/AAAAAAAAAN0/fg_7r04lU1A/RP_DataCollection_2.png.png?imgmax=800" alt="Back Channel RP Data Collection" width="375" height="194" border="0" />How will you move the verified attributes from an IdP/CSP/AP to the RP?</li><li>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?</li><li>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?</li><li>Does the ability to capture and pass consent regarding attribute release exist?</li></ul><p><br /> 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.<br /> <br /> Feedback on how you are implementing these types of capabilities in your Enterprise would be appreciated. Are there additional or different approaches or considerations?</p><div><strong>RELATED POSTS</strong></div><div><ul><li><a href="http://info.idmanagement.gov/2012/06/how-to-verify-citizen-identity-easily.html">How to Verify Citizen Identity Easily and Effectively</a></li><li><a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">If You Don't Plan For User Enrollment Now, You'll Hate Federation Later</a></li><li><a href="http://info.idmanagement.gov/2012/04/assurance-level-escalation-and.html">Assurance Level Escalation and Government Relying Parties</a></li><li><a href="http://info.idmanagement.gov/2012/10/challenges-in-operationalizing-privacy_29.html">Challenges in Operationalizing Privacy in Identity Federations - Part 3</a></li></ul></div><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-63280848506840444732012-09-16T07:00:00.000-04:002013-01-09T21:46:07.804-05:00Attributes Anytime, Anywhere. Extending BAE to Support New Protocols<p>The <a href="http://info.idmanagement.gov/2012/09/from-aaes-to-bae-implementing.html">Backend Attribute Exchange (BAE) Capability</a> implements a pure Attribute Provider and, by deliberate design, does not provide any authentication functionality. The current technical implementation of the BAE supports a <a href="http://www.idmanagement.gov/documents/BAE_v2_SAML2_Profile_Final_v1.0.0.pdf">secure FICAM Profile of SAML 2.0 Assertion Query and Response (PDF)</a> which is bound to SOAP. In this blog post, <strong>and as a thought exercise</strong>, 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.<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="BAE_FutureProtocols.png" src="http://lh4.ggpht.com/-tLcaVQ7XKHE/UFVLeJoyuMI/AAAAAAAAANc/DwwkNEmvMqw/BAE_FutureProtocols.png?imgmax=800" alt="BAE Future Protocols?" width="500" height="250" border="0" /><br /> <strong><br /></strong> <strong>XACML</strong><br /> <br /> 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 <strong>need to provide a capability to verify self-asserted attributes rather than pure attribute retrieval</strong>:</p><ol><li>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</li><li>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</li><li>The attribute provider responds with a boolean "Yes|No" and clarification/error data as appropriate</li></ol><p>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:</p><ul><li>The ability to send multiple attributes and values in and the ability to get a Yes|No or a Match|NoMatch decision back</li><li>Attribute Categories (pre-defined and custom) for <span style="font-family: 'Courier New'; font-size: 12px;"><Subject></span>, which can carry the self-asserted attributes of the subject, and <span style="font-family: 'Courier New'; font-size: 12px;"><Resource></span>, which can be used to route the request to the appropriate authoritative sources</li><li>The request message allows for capturing the consent of the <span style="font-family: 'Courier New'; font-size: 12px;"><Subject></span> for attribute release</li><li>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)</li><li>Ability to layer in cross-cutting security functionality, at both the message and transport level using existing infrastructure</li></ul><p>The BAE could potentially support this as an additional interface that can in effect act as the technical pieces of an Identity Oracle.<br /> <strong><br /></strong> <strong>OAUTH 2</strong><br /> <br /> 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 <strong>more about implementing a pure Attribute Provider functionality using a profile of <a href="http://tools.ietf.org/id/draft-ietf-oauth-v2-31.html">OAUTH 2</a> rather than supporting the full OAUTH 2 IdP functionality</strong>.<br /> <br /> 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 <a href="http://openid.net/specs/openid-connect-standard-1_0.html#userinfo_ep">UserInfo Endpoint. This endpoint is simply an OAUTH 2 Protected Resource with some specific communication semantics</a>:</p><ul><li>It requires that an Access Token be sent to it (i.e. UserInfo Request is sent as an OAUTH2 Bearer Token)</li><li>It returns attributes in cleartext JSON or if needed as a signed/encrypted JWT (i.e. UserInfo Response)</li></ul><p>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.<br /> <br /> The BAE could potentially support this as an additional Attribute Provider interface, and depending on the Authorization Server (OpenID Connect) or Authorization Manager (<a href="http://docs.kantarainitiative.org/uma/draft-uma-core.html">UMA</a>) based OAUTH 2 flows, could support the appropriate semantics in the request and response.<br /> <br /> Comments and perspectives on both are welcome!<br /> <strong><br /></strong> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/09/from-aaes-to-bae-implementing.html">From AAES to BAE - Implementing Collection and Sharing of Identity Data</a></li><li><a href="http://info.idmanagement.gov/2012/09/what-is-new-with-bae-operational.html">What is new with the BAE Operational Deployment?</a></li><li><a href="http://info.idmanagement.gov/2012/04/shared-services-and-government-as.html">Shared Services and Government as Attribute Service Provider</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-5210328721855918882012-09-09T07:00:00.000-04:002013-01-09T21:46:37.368-05:00From AAES to BAE - Implementing Collection and Sharing of Identity Data<p>The <a href="http://www.idmanagement.gov/documents/FICAM_Roadmap_and_Implementation_Guidance_v2%200_20111202.pdf">Federal Identity, Credential and Access Management (FICAM) Roadmap and Implementation Guidance</a> (PDF) calls out the need to implement the ability to streamline the collection and sharing of digital identity data (Initiative 5). The <strong>Authoritative Attribute Exchange Services (AAES) is the architectural construct</strong> 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 <strong>deploying a Backend Attribute Exchange (BAE) infrastructure</strong>.<br /> <br /> <strong>The AAES is a point of architectural abstraction</strong> between authoritative sources of identity information and the systems and applications that need that information.<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="FICAM_AAES.png" src="http://lh4.ggpht.com/-ZIKO4sClOx4/UEwh20bIWfI/AAAAAAAAAM8/2SCwdZyOwnw/FICAM_AAES.png?imgmax=800" alt="FICAM AAES" width="500" height="369" border="0" /><br /> <br /> At a high level, you can separate the functional requirements of an AAES into two buckets:</p><table style="width: 80%px;" border="1" cellspacing="0" cellpadding="5" align="center"><tbody><tr><th width="50%">Authoritative Attribute Manager</th><th width="50%">Authoritative Attribute Distributer</th></tr><tr><td valign="top"><ul><li>Correlate attributes from various attribute sources</li><li>De-conflict discrepancies across attribute sources</li><li>Implement a data model for entity attributes</li><li>Provide a consolidated view of the pieces of an entity gathered from multiple sources</li></ul></td><td valign="top"><ul><li>Primary point of query for systems and applications</li><li>Provide a customized and tailored view of data</li><li>Support requests for attributes from both internal and external (to organization standing up the AAES) consumers</li></ul></td></tr></tbody></table><p><br /> 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.<br /> <br /> A combination of a Virtual/Meta Directory Engine and a XML Security Gateway provides such a mix of capabilities:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="FICAM_AAES_2.png" src="http://lh5.ggpht.com/-JQbybwgeXGY/UEwh3c9ThEI/AAAAAAAAANE/i-8CnNtSLsA/FICAM_AAES_2.png?imgmax=800" alt="FICAM AAES Implementation" width="575" height="413" border="0" /><br /> 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 <a href="http://info.idmanagement.gov/2012/09/what-is-new-with-bae-operational.html">Backend Attribute Exchange (BAE) infrastructure we are currently deploying</a>:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="FICAM_AAES_BAE.png" src="http://lh5.ggpht.com/-pbp-7zmY8ZY/UEwh4KjsTRI/AAAAAAAAANM/PWCwphWGDps/FICAM_AAES_BAE.png?imgmax=800" alt="FICAM AAES BAE" width="575" height="414" border="0" /><br /> <br /> As you can see above, there are also two supporting elements to the BAE infrastructure that we have deployed/are deploying; <strong>the BAE Metadata Service and the E-Government Trust Services (EGTS) Certificate Authority (CA)</strong>. 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".<br /> <br /> In short, <strong>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</strong>. 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.<br /> <br /> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/09/what-is-new-with-bae-operational.html">What is new with the BAE Operational Deployment?</a></li><li><a href="http://info.idmanagement.gov/2012/04/shared-services-and-government-as.html">Shared Services and Government as Attribute Service Provider</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-83641874666227577422012-09-01T07:00:00.000-04:002013-01-09T21:46:59.187-05:00What is new with the BAE Operational Deployment?<p>GSA OGP, together with our partner <a href="http://ise.gov/">PM-ISE</a>, is moving out on the operational deployment of the <a href="http://info.idmanagement.gov/2012/04/shared-services-and-government-as.html">FICAM Backend Attribute Exchange</a> (BAE). The PM-ISE blog post "<a href="http://ise.gov/blog/michael-e-kennedy/detailed-test-scenario-our-law-enforcement-backend-attribute-exchange-pilot">A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot</a>" 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.<br /> <br />The operational scenario looks like this:<br /> <br /> <img style="display: block; margin-left: auto; margin-right: auto;" title="BAE_OpPilot_1.png" src="http://lh6.ggpht.com/-mWUGxTkmyQ8/UEEGR8wVAwI/AAAAAAAAAMU/ZqoU4uFCdgU/BAE_OpPilot_1.png?imgmax=800" alt="BAE Operational Pilot Flow" border="0" /><br /> In any such scenario, there are always three parties to the transaction. An Identity Provider, a Relying Party and an Attribute Provider.</p><blockquote><em>"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.<br /><br />In the course of an investigation, the officer needs to access data on the RISS-Net system."</em></blockquote><p><strong>J-NET is the Identity Provider and RISS-Net Portal is the Relying Party</strong>.</p><blockquote><em>"… 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."</em></blockquote><p>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.<strong> 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</strong>.<br /> <br /> One of the critical technical benefits of this relationship, within the context of the BAE deployment, <a href="http://gfipm.net/standards/metadata/2.0/user/FederationId.html">is that the Federation Identifier has been standardized across NIEF</a> (gfipm:2.0:user:FederationId).<br /> <br /> When we created the "<a href="http://www.idmanagement.gov/documents/BAE_v2_SAML2_Profile_Final_v1.0.0.pdf">SAML 2.0 Identifier and Protocol Profiles for BAE v2.0</a>" (PDF), <strong>we deliberately separated out the profiling of the identifiers and the profiling of the protocols precisely so that we could "snap-in" new identifiers,</strong> without impacting the security of the protocol. We also put in some specific wording that allowed this flexibility; "<em>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.</em>"<br /> <br /> 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.</p><blockquote><em>"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."</em></blockquote><p>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.</p><blockquote><em>"… 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."</em></blockquote><p>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 <em>28CFRPart23</em> attribute is provided. J-Net is not able to assert this, but <strong>BJA as the authoritative attribute source </strong>can. And we are utilizing the BAE Shared Service Infrastructure deployed at GSA to provide them the capability to do so.<br /> <br /> 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.<br /> <br /> 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!<br /> <strong><br /></strong> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/09/from-aaes-to-bae-implementing.html">From AAES to BAE - Implementing Collection and Sharing of Identity Data</a></li><li><a href="http://ise.gov/blog/michael-e-kennedy/detailed-test-scenario-our-law-enforcement-backend-attribute-exchange-pilot">PM-ISE: A Detailed Test Scenario for our Law Enforcement Backend Attribute Exchange Pilot</a></li><li><a href="http://info.idmanagement.gov/2012/04/shared-services-and-government-as.html">Shared Services and Government as Attribute Service Provider</a></li><li><a href="http://ise.gov/blog/michael-e-kennedy/advancing-identity-access-management-idam-pilot-project-pennsylvania">PM-ISE: Advancing Identity Access Management (IdAM) with a Pilot Project in Pennsylvania</a></li></ul><p><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-6816173721599253412012-08-25T14:44:00.000-04:002012-08-26T00:35:08.421-04:00How the US Federal Government Participates in the NSTIC IDESG<div style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;"><br /> <img style="float: right;" title="NSTIC.png" src="http://lh6.ggpht.com/-UdQZAePFlJo/UDkVgXnvPmI/AAAAAAAAAME/_eJzJ8-fUaA/NSTIC.png?imgmax=800" alt="NSTIC" width="240" height="320" border="0" /></div><p>The National Strategy for Trusted Identities in Cyberspace (NSTIC) <a href="http://nstic.blogs.govdelivery.com/2012/08/23/nstic-implementation-hits-an-important-milestone-the-identity-ecosystem-steering-group-exists/">Identity Ecosystem Steering Group (IDESG) has been launched</a> 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.<br /> <br /> Congratulations to Jeremy Grant and the <a href="http://www.nist.gov/nstic/">NSTIC National Program Office</a> on their hard work in reaching this important milestone.<br /> <br /> The <a href="http://www.idecosystem.org/page/management-council">Management Council of the IDESG</a> is composed of Officers and Delegates from the various Stakeholder Groups. The US Federal Government is but one of the Stakeholders, and <strong>FICAM's own Deborah Gallagher has been elected as the US Federal Government's Delegate to the IDESG Management Council</strong>. She will be coordinating and bringing the US Federal Government's perspective to the IDESG.<br /> <br /> On the FICAM side of the house, we are sometimes asked what our relationship to NSTIC is. The answer is rather simple; <strong>FICAM is the US Federal Government's implementation of the NSTIC Vision and Principles</strong>. 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.<br /> <br /> <strong>RELATED INFO</strong></p><ul><li><a href="http://www.idecosystem.org/">NSTIC Identity Ecosystem Steering Group</a> (IDESG)</li><li><a href="http://www.idecosystem.org/page/plenary-groups">Identity Ecosystem Steering Group Plenary Groups</a></li><li><a href="http://www.idecosystem.org/page/management-council">Identity Ecosystem Steering Group Management Council</a></li><li><a href="http://www.whitehouse.gov/sites/default/files/rss_viewer/NSTICstrategy_041511.pdf">National Strategy for Trusted Identities in Cyberspace</a> (PDF)</li></ul><p><br /> <small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-81815607014524215602012-08-13T22:24:00.001-04:002013-01-09T21:47:51.084-05:00What is new in the FICAM Trust Framework Provider Adoption Process?<p>The <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Trust Framework Provider Adoption Process</a> (TFPAP) is the mechanism used by the Government to leverage industry-based credentials, that citizens already have, for use at Government web sites.<br /><br /></p><div class="separator" style="clear: both; text-align: center;"><a style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;" href="http://4.bp.blogspot.com/-_XagitiYq8g/UCmwrHQdpVI/AAAAAAAAALw/eFWElcv9eis/s1600/TFPAP.png"><img src="http://4.bp.blogspot.com/-_XagitiYq8g/UCmwrHQdpVI/AAAAAAAAALw/eFWElcv9eis/s320/TFPAP.png" alt="" width="320" height="175" border="0" /></a></div><p>The current version of the <a href="http://www.idmanagement.gov/documents/TrustFrameworkProviderAdoptionProcess.pdf">Trust Framework Provider Adoption Process (PDF)</a> was finalized in 2009. Since that time there has been great progress in E-Government activities, such as the launching of the <a href="http://www.nist.gov/nstic/">National Strategy for Trusted Identities in Cyberspace (NSTIC)</a> and the decision to <a href="http://info.idmanagement.gov/2012/07/gsa-announces-industry-day-on-federal.html">move out on the FCCX initiative</a>.<br /> <br /> 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.<br /> <br /> 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:</p><ul><li>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. </li><li>Privacy Guidance, which was separately developed by the FICAM will be updated and integrated directly into the new TFPAP.</li><li>Exploring how best to bring the TFPAP to bear on the Identity Provider / Attribute Provider / Relying Party aspects individually, and together.</li><li>Integrating a robust and ongoing Test and Evaluation program into the TFPAP</li><li>More...</li></ul><p>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.<br /> <br /> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Trust Framework Solutions - A Primer</a></li><li><a href="http://info.idmanagement.gov/2012/07/gsa-announces-industry-day-on-federal.html">GSA OGP Announces an Industry Day on Federal Federated Identity Solutions</a></li></ul><p><br /><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-68399260407410175242012-08-04T14:32:00.000-04:002013-01-09T21:48:14.305-05:00RFI/RFP Language for Federation Solutions and Identity Proofing Solutions<div class="separator" style="clear: both; text-align: center;"><a style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;" href="http://3.bp.blogspot.com/-x3H5ndaPuDQ/T1lLwRAX4II/AAAAAAAAAFs/W4oE6UPGDIw/s1600/FICAM_Logo.png"><img src="http://3.bp.blogspot.com/-x3H5ndaPuDQ/T1lLwRAX4II/AAAAAAAAAFs/W4oE6UPGDIw/s1600/FICAM_Logo.png" alt="" border="0" /></a></div><p>As noted in my earlier blog post "<a href="http://info.idmanagement.gov/2012/06/comply-with-requirements-quickly-and.html">Comply with Requirements Quickly and Easily with RFI and RFP Templates</a>", 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.<br /> <br /> <strong>Identity Federation Solution for Agency as Relying Party</strong></p><ul><li>The solution shall support all currently <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">approved FICAM Protocol Profiles</a>, as found on IDManagement.gov, for browser based SSO (OpenID 2.0 and SAML 2.0 required; IMI 1.0 support is optional)</li><li>The solution shall support newly approved FICAM Protocol profiles, as found on IDManagement.gov, within [90 days] of final approval by the ICAMSC</li><li>The solution shall be capable of supporting all <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Adopted Trust Framework Provider</a> Approved Credential Providers</li><li>The solution shall be capable of supporting PIV (for Government-to-Government use cases) and PIV-I Authentication. This support must include <a href="http://info.idmanagement.gov/2012/03/what-is-certificate-path-discovery-and.html">Trust Path Discovery and Trust Path Validation</a> functionality</li><li>If the solution implements a SAML 2.0 Attribute Query/Response mechanism, it shall support the <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">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</a></li><li>The solution shall, at a minimum, support the following protocols and assertion formats for communication between itself and the relying party Agency application:</li><ul><li>Protocols: HTTP(S), SAML 2.0</li><li>Assertion Formats: SAML 2.0, XML, JSON</li></ul></ul><p>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.<br /> <br /> <strong>Identity Proofing Service</strong></p><ul><li>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</li></ul><p>Details: <a href="http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf">NIST SP 800-63-1</a>(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 <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">Trust Framework Adoption Process</a>, 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.<br /> <br /> Do keep in mind the following:</p><ul><li>The focus above is on the technical bits-n-bytes</li><li>The above is just a starting point; Agencies are free to modify and add on other requirements as needed</li><li>The above is subject to change based on new and/or updated policies</li></ul><p><strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/06/comply-with-requirements-quickly-and.html">Comply with Requirements Quickly and Easily with RFI and RFP Templates</a></li><li><a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Trust Framework Solutions - A Primer</a></li><li><a href="http://info.idmanagement.gov/2012/04/shared-services-and-government-as.html">Shared Services and Government as Attribute Service Provider</a></li></ul><p><br /><small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-51059352063645605542012-07-27T12:32:00.000-04:002013-01-09T21:48:39.269-05:00GSA OGP Announces an Industry Day on Federal Federated Identity Solutions<p>Earlier this year, the White House convened the Federal Cloud Credential Exchange (FCCX) Tiger Team comprised of several federal agencies that have a <strong>vital need to better assist the public and reduce Federal costs by moving more services online</strong>. In alignment with President Obama’s <a href="http://www.nist.gov/nstic">National Strategy for Trusted Identities in Cyberspace</a>, the FCCX Tiger Team’s objective is to facilitate the Federal government’s early adoption of <strong>secure, privacy-enhancing, efficient, easy-to-use, and interoperable identity solutions.</strong><br /> <strong><br /></strong>Over the past few months, the FCCX Tiger Team has worked on the use cases and the functional requirements necessary for the operation of an identity federation capability that can be integrated with a government agency web application to support and consume a full range of digital credentials such as PIV, PIV-I, and other third party credentials issued under a <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM-approved Trust Framework Provider</a>.<br /> <br /> In simple terms, the Federal government is interested in leveraging one or more commercially available cloud service providers to streamline the burden agencies face in trusting and integrating with FICAM-approved credentials.<br /> <br /> As the next step, the FCCX Tiger Team would like to hear from industry vendors on how they might implement a privacy-enhancing, cloud-based, federated credential exchange service.<br /> <br /> If you are a product or solutions provider that has the ability to offer these capabilities and would like to help inform the service, please <strong>submit your name and company</strong> via e-mail to <em>icam [at] gsa [dot] gov</em> <strong>by Wednesday, August 1, 2012</strong> and we will provide more information about the requested written response and associated logistics.<br /> <br /> In addition, for those who contact us, GSA Office of Governmentwide Policy (GSA OGP) will be holding an<strong> Industry Day on Tuesday, August 7th, 2012 (9am – 12:30pm EST)</strong> at GSA OCS, 1275 First Street NE, Washington DC, Room 1201B (NoMa-Gallaudet Station – DC Metro Red Line) to gather more information and answer questions from industry vendors regarding the FCCX initiative. We will be able to host both virtually and in person. In person space is limited, so let us know your preference when you contact us.<br /> <br /> As an overview, the following topics should be addressed in your <strong>written response</strong> which will be <strong>due by 5 P.M. EDT on Monday, August <span style="text-decoration: line-through;">13</span> 20, 2012</strong>:</p><ul><li>Proposed high level architecture for enabling authentication to an Agency application using third party credentials to include:</li><ul><li>Shared service operated in a cloud environment servicing multiple Agencies</li><li>Operation in an Agency-hosted environment</li></ul><li>User interface approaches for selection of approved credentials</li><li>Credential registration and authentication strategies for citizens with multiple approved credentials</li><li><a href="http://info.idmanagement.gov/2012/06/if-you-don-plan-for-user-enrollment-now.html">User enrollment</a> approaches</li><li><a href="http://info.idmanagement.gov/2012/04/assurance-level-escalation-and.html">Assurance level escalation</a> approaches</li><li>Attribute request/consumption approaches</li><li>Supported <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Scheme">protocols, profiles and schemas</a> for creating and sending assertions</li><li>Abstracting and streamlining business relationships with FICAM approved credential providers at all levels of assurance</li><li>Preserving privacy (minimize storage of personal information and “panopticality” of the service)</li><li>Auditing</li><li>Scalability of the service</li><li>Costs models (Pay per User or application using tiered volume discounts, O&M)</li><li>Other relevant information</li></ul><p><strong>UPDATE (8/3/12)</strong>: We've had a couple of questions about what is meant by "panopticality" above.</p><blockquote><p>Within the context of FCCX it means two things:</p><ol><li>It is the ability of Credential Providers to "see" all the Service Providers to which a citizen authenticates</li><li>It is the visibility that the FCCX service itself may have into the citizen information that is flowing thru it</li></ol></blockquote><p><br /><small>:- by Deb Gallagher (GSA) & Naomi Lefkovitz (NIST) - FCCX Tiger Team Co-Chairs</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-29258408516717148432012-07-07T07:00:00.000-04:002013-01-09T21:49:09.012-05:00Access Control and Attribute Management WG Industry Day Invitation<p>The FICAM <a href="http://info.idmanagement.gov/2012/03/access-control-and-attribute-management.html">Access Control & Attribute Management Working Group (ACAGWG)</a> is working to address the needs of the Federal Government for access control, lifecycle management of attributes, and the associated governance processes around entitlements and priveleges. If you are interested in engaging with this cross-government (Federal, Defense, IC and more…) working group during our upcoming industry day, please read on...<br /> <a style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;" href="http://1.bp.blogspot.com/-dJC472yDCWs/T18q67km1HI/AAAAAAAAAGI/sZluzx9gFns/s1600/ICAM_ACAGWG.png"><img src="http://1.bp.blogspot.com/-dJC472yDCWs/T18q67km1HI/AAAAAAAAAGI/sZluzx9gFns/s320/ICAM_ACAGWG.png" alt="" width="320" height="200" border="0" /></a><br /> Why are we holding this event?</p><blockquote>We have little desire to re-invent the wheel and would like to leverage lessons learned and best practices from real world implementations.<span style="background-color: white;"> </span></blockquote><blockquote>This event is designed to help us learn more about the current state-of-practice in the commercial sector around attribute providers and their business models, as well as identity and access governance approaches.</blockquote><p>When and where is this event being held?</p><blockquote>September 5, 2012 in the Washington, DC area. </blockquote><p>What are we are looking for?</p><blockquote>A demonstrated case study (references to operational systems are preferred) to include information such as:<br /><ol><li>Attribute lifecycle management</li><li>Provisioning/de-provisioning of attributes</li><li>Processes for semantic and syntactic alignment of attributes</li><li>Attestation of attributes</li><li>Provenance of attributes</li><li>Attribute metadata</li><li>Data quality management and practices of attribute providers</li><li>Attribute provider business models</li><li>Defining, generating and sharing access policies</li><li>Enterprise privilege and entitlement management practices</li><li>Separation of duties</li><li>Other topics related to Attribute Providers as well as Identity and Access Governance</li></ol>Elements the case study should explore and include:<br /><ol><li>The type of infrastructure in place</li><li>Processes in place for managing attributes</li><li>The process for deciding the appropriate attribute and access policies for the domain</li><li>Determining Levels of confidence in attribute providers</li><li>What factors go into making a decision to "trust" an attribute provider</li><li>Design time vs. run-time decision factors</li><li>Expanded uses beyond the original intent of the attribute and access policies</li></ol></blockquote><p>What are we NOT looking for?</p><blockquote><ul><li>Product demos</li><li>Marketing slide-ware</li></ul><div>This is a group that has deep technical and policy expertise. We are fine with you taking some time at the end of the case study to map it into your product/service. The majority of the case study, however, should focus on the concept of operations, business models, processes and decisions that went into the case study. </div></blockquote><p>What is the first step?</p><blockquote>Please submit a one page high-level abstract (PDF) with details of your case study to ICAM [at] gsa [dot] gov by 5:00 p.m. on July 31st, 2012. A member of our planning committee will be in contact with those whose submissions most closely align with what we are seeking.</blockquote><p><br /> <small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-27784638491867051422012-06-30T07:00:00.000-04:002012-08-27T15:07:41.332-04:00New FICAM Guidance on using PIV and PIV-I Cards in Agency PACS<p>Incorporating stronger authentication technologies in an Agency Physical Access Control System (PACS), such as PIV and PIV-I cards, is a critical aspect of mitigating the risk of physical security breaches. FICAM recently published the "<a href="http://www.idmanagement.gov/documents/EPACS_v2.0.2.pdf">Personal Identity Verification (PIV) in Enterprise Physical Access Control Systems (E-PACS)</a>" (PDF) document which provides detailed technical and security guidance for leveraging PIV and PIV-I authentication mechanisms in a federal agency PACS.<br /> <br /> This is a comprehensive document that covers:</p><ul><li>The current PACS landscape</li><li>The current standards and guidance that directly or indirectly affect PACS</li><li>Enterprise PACS security functions, which describe specific and measurable security controls that impact the successful operation of PACS as a security countermeasure</li><li>A comprehensive list of common authentication patterns that illustrate both proper and improper use of PIV and PIV-I authentication </li></ul><p><img style="float: right;" title="E-PACS.png" src="http://lh6.ggpht.com/-U1I_7odbB6k/T-4gnMvP_tI/AAAAAAAAALc/1iUfHZszS-w/E-PACS.png?imgmax=800" alt="E PACS" width="400" height="299" border="0" /><br /> The Enterprise PACS security functions are broken down into:</p><ul><li>Technical Controls</li><ul><li>Identification and Authentication</li><li>Access Control</li><li>Audit and Accountability</li><li>System and Communications Protection</li></ul><li>Operational Controls</li><ul><li>Configuration Management</li><li>Contingency Planning</li><li>Physical and Environmental Protection</li><li>System and Information Integrity</li><li>Awareness and Training</li></ul><li>Management Controls</li><ul><li>Security Assessment and Authorization</li><li>Planning</li><li>Risk Assessment</li></ul></ul><p>The authentication patterns, which include both good and not-so-good patterns, are one of the more informative parts of this document. They in turn align with the <a href="http://csrc.nist.gov/publications/nistpubs/800-116/SP800-116.pdf">NIST SP 800-116 (PDF)</a> authentication mechanisms as they pertain to gaining access to security areas.<br /> <br /> The patterns themselves are provided using a standard format:</p><ul><li>Use Case Diagram</li><li>Description</li><li>Unmitigated Threats</li><li>Pros, Cons, Issues</li><li>Considerations</li></ul><p>This document, which was produced by the FICAM Architecture Working Group, was a significant undertaking and reflects the many perspectives that go into deploying an effective PACS. The newly established FICAM Modernized Physical Access Working Group (MPAWG) will manage updates and changes to this document.<br /> <br /> <strong>RELATED INFORMATION</strong></p><ul><li><a href="http://www.idmanagement.gov/documents/Personal_Identity_Verification_in_Enterprise_Physical_Access_Control_Systems_v2_0_2.pdf">Personal Identity Verification (PIV) in Enterprise Physical Access Control Systems (E-PACS) v2.0.2 DRAFT</a> (PDF) @ <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM">IDManagement.gov</a> </li></ul><p><br /> <small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-13891037835825447272012-06-21T18:48:00.000-04:002013-01-09T21:49:52.758-05:00New Kantara Assessment Process Provides Flexibility While Maintaining Rigor<p>FICAM's <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">Trust Framework Adoption Process</a> allows us to use <strong>comparability</strong> criteria to adopt industry trust frameworks for use by the Government. Flexibility and innovation in managing the process are critical to making sure Government requirements can take advantage of innovation in the industry. <span style="background-color: white;">Kantara Initiative, </span><a style="background-color: white;" href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-Provider">one of our approved Trust Framework Providers</a> (TFPs)<span style="background-color: white;">, recently updated their assessment criteria in a manner that continues to meet the requirements of FICAM and NIST, while at the same time providing flexibility in assessing solution providers.</span><br /> <br /> <a style="clear: right; float: right; margin-bottom: 1em; margin-left: 1em;" href="http://2.bp.blogspot.com/-6zGLIss33eY/T-MLjch12-I/AAAAAAAAALQ/cySP10V1gJs/s1600/kantara_logo.gif"><img title="" src="http://2.bp.blogspot.com/-6zGLIss33eY/T-MLjch12-I/AAAAAAAAALQ/cySP10V1gJs/s1600/kantara_logo.gif" alt="Kantara Initiative Logo" border="0" /></a>Kantara's trust framework, which has been approved by FICAM, is called the <a href="http://kantarainitiative.org/confluence/x/EYCYAQ">Kantara Initiative Identity Assurance Framework</a>. A critical component of it is the Service Assessment Criteria which establishes baseline criteria for general organizational conformity, identity proofing services, credential strength, and credential management services against which all <a href="http://kantarainitiative.org/wordpress/programs/assurance/">FICAM Credential Service Providers</a> are verified for assurance.<br /> <br /> General thinking of the TFPs has been a single entity would perform all activities of a solution, but it has always been feasible under the Trust Framework Solutions process to have separate entities doing the identity proofing and credential issuance functions. Kantara has restructured their Identity Assurance Service Assessment Criteria to accommodate independent assessment of these functions, which in turn can now be offered by different providers as a component of the complete solution.<br /> <br /> In line with how the <a href="http://info.idmanagement.gov/2012/04/electronic-authentication-mobility-and.html">E-Authentication model in NIST SP 800-63</a> provides for logical and physical separation between the Registration/Identity-Proofing function and the Token/Credential Management function, Kantara's restructured service assessment criteria performs assessments across two dimensions:</p><ol><li>Organizational Assessment, which is required of all entities undergoing assessment</li><li>Operational Criteria Assessment, which covers the actual component services being offered</li></ol><p>The flexibility in this approach comes from the fact that <strong>multiple organizations, each with its own unique service offering, can now come together to offer component services.</strong> The restructured assessment criteria now allows for these individual service components to be assessed independently. These services can be unique to each assurance level, but taken together provides a full service capability that combines both Registration/Identity-Proofing and Credential Management.<br /> <br /> This approach provides significant opportunities for partnering between organizations, which can now put together unique and tailored solutions that, in total, satisfy the service assessment criteria. From the FICAM perspective, it is important to note that <strong>we apply the "FICAM Approved" label only to the total package made up of the various service components</strong> that together offer the complete Registration/Identity-Proofing and Credential Management functions.<br /> <br /> National Institute of Standards and Technology (NIST) and General Services Administration (GSA) personnel welcome this new approach from Kantara, which without reducing the rigor of the assessment criteria, allows for innovative industry partnering as well as tailored and flexible service offerings to the Government.<br /> <br /> <strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM Trust Framework Solutions - A Primer</a></li></ul><p><br /> <small>:- by Deb Gallagher</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.comtag:blogger.com,1999:blog-5148685713465805663.post-19913414144031334912012-06-16T07:00:00.000-04:002013-01-09T21:50:10.057-05:00Comply with Requirements Quickly and Easily with RFI and RFP Templates<p>A challenge agencies face when putting out an RFI/RFP is in making sure that the intent of the policies and guidance they need to comply with comes through. From the perspective of the organizations that are responsible for policy and guidance, Agencies getting the language right in the RFI/RFP closes the loop by <a href="http://gsablogs.gsa.gov/ogpblogteam/2012/04/26/enhancing-our-acquisition-policy-and-increasing-interoperability/">aligning acquisitions with standards and policy</a>. When it comes to Federal Government Agency Identity, Credential and Access Management RFIs and RFPs, FICAM is working to make this easier for Agencies.<br /> <br /> We have taken note of the increased RFIs and RFPs for ICAM components that are going out. At the same time, we also realize that the hard working folks who are putting these together face challenges when it comes to making sure that the language in the RFI/RFP reflect the required technical standards and policies.<br /> <br /> Let me use language from a recent Agency RFI to discuss how we can help:</p><blockquote><em>[...] requirement of integrating remote/on-line proofing functionality into the [Agency's Identity and Access Management Capability] Identity Proofing Services. To be capable of meeting this requirement, a vendor:</em><br /><ul><li><em>Must currently hold a Level 2 FICAM certification</em></li><li><em>Shall have the ability to achieve a Level 3 FICAM certification by [Future Date]</em></li><li><em>[More …]</em></li></ul></blockquote><p>The above sounds reasonable, but there is a problem; <strong>there currently is NO FICAM certification for a stand-alone identity proofing capability</strong>. <a href="http://info.idmanagement.gov/2012/05/ficam-trust-framework-solutions-primer.html">FICAM certification, via our adopted Trust Framework Providers</a>, currently applies only to a <a href="http://www.idmanagement.gov/pages.cfm/page/ICAM-TrustFramework-IDP">combined identity proofing and credential issuance solution</a>. By using the language of FICAM certification above and associating it only with ID Proofing, the results end up being:</p><ul><li>Confusion in the market about what exactly is being asked for</li><li>Limiting and/or eliminating qualified vendors who may be able to meet the actual intended requirements</li></ul><div>Given that this is a Federal Government Agency who has to comply with OMB Levels of Assurance (LOA) requirements and the associated NIST technical implementation guidance for remote identity proofing, the solution to the above is a minor tweak to the language to convey the actual intent:</div><div><ul><li><em>Must have an identity proofing service capable of implementing remote identity proofing process at LOA 2 per <a href="http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf">NIST 800-63-1</a></em></li><li><em>Shall have the ability to implement remote identity proofing processes at LOA 3 per <a href="http://csrc.nist.gov/publications/nistpubs/800-63-1/SP-800-63-1.pdf">NIST 800-63-1</a> by [Future Date]</em></li></ul></div><p>So, in order to help the Agencies up-front to comply with OMB, NIST and FICAM guidance, we are currently working on standardized technical language/templates for specific ICAM capabilities (Identity Proofing, Identity Federation etc.). Agencies will be able to easily incorporate this standard language into their RFI/RPF going forward.<br /> <br /> If you are an Agency looking for information on ICAM components or policy for an RFI/RFP you are putting together, please feel free to contact us at icam (at) gsa (dot) gov and we would be happy to answer your questions.</p><p><strong>RELATED POSTS</strong></p><ul><li><a href="http://info.idmanagement.gov/2012/08/rfirfp-language-for-federation.html">RFI/RFP Language for Federation Solutions and Identity Proofing Solutions</a></li></ul><p><br /> <small>:- by Anil John</small></p>Anil Johnhttps://plus.google.com/100388321592797981516noreply@blogger.com