Challenges in Operationalizing Privacy in Identity Federations - Part 3

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

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

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

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

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

The RP then initiates the attribute verification process:

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

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

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

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

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

RELATED POSTS

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

:- by Anil John

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

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

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

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

1. Determine the minimal set of attributes

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

2. Implement PII Protection on collected attributes 

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

3. Who will collect and verify the attributes?

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

4. How will you securely move the attributes?

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

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

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

RELATED POSTS

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

:- by Anil John

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

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

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

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

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

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

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

RELATED POSTS

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

:- by Anil John

New Kantara Assessment Process Provides Flexibility While Maintaining Rigor

FICAM's Trust Framework Adoption Process allows us to use comparability 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. Kantara Initiative, one of our approved Trust Framework Providers (TFPs), 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.

Kantara's trust framework, which has been approved by FICAM, is called the Kantara Initiative Identity Assurance Framework. 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 FICAM Credential Service Providers are verified for assurance.

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.

In line with how the E-Authentication model in NIST SP 800-63 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:

1. Organizational Assessment, which is required of all entities undergoing assessment
2. Operational Criteria Assessment, which covers the actual component services being offered

The flexibility in this approach comes from the fact that multiple organizations, each with its own unique service offering, can now come together to offer component services. 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.

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 we apply the "FICAM Approved" label only to the total package made up of the various service components that together offer the complete Registration/Identity-Proofing and Credential Management functions.

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.

RELATED POSTS

• FICAM Trust Framework Solutions - A Primer

:- by Deb Gallagher

Comply with Requirements Quickly and Easily with RFI and RFP Templates

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 aligning acquisitions with standards and policy. When it comes to Federal Government Agency Identity, Credential and Access Management RFIs and RFPs, FICAM is working to make this easier for Agencies.

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.

Let me use language from a recent Agency RFI to discuss how we can help:

[...] 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:

• Must currently hold a Level 2 FICAM certification
• Shall have the ability to achieve a Level 3 FICAM certification by [Future Date]
• [More …]

The above sounds reasonable, but there is a problem; there currently is NO FICAM certification for a stand-alone identity proofing capability. FICAM certification, via our adopted Trust Framework Providers, currently applies only to a combined identity proofing and credential issuance solution. By using the language of FICAM certification above and associating it only with ID Proofing, the results end up being:

• Confusion in the market about what exactly is being asked for
• Limiting and/or eliminating qualified vendors who may be able to meet the actual intended requirements

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:

• Must have an identity proofing service capable of implementing remote identity proofing process at LOA 2 per NIST 800-63-1
• Shall have the ability to implement remote identity proofing processes at LOA 3 per NIST 800-63-1 by [Future Date]

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.

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.

RELATED POSTS

• RFI/RFP Language for Federation Solutions and Identity Proofing Solutions

:- by Anil John

If You Don't Plan For User Enrollment Now, You'll Hate Federation Later

User enrollment (a.k.a. user activation, user provisioning, account mapping) into a relying party (RP) application is one of those pesky details that is often glossed over in identity federation conversations. But this piece of the last mile integration with the relying party is fundamental to making identity federation work. This blog post describes this critical step and its components.

Enrollment is defined here as the process by which a link is established between the (credential) identifier of a person and the identifier used within an RP to uniquely identify the record of that person. For the rest of this blog post, I am going to use the term Program Identifier (PID) to refer to this RP record identifier [A hat tip to our Canadian colleagues].

Especially when it comes to government services, a question that needs to be asked is if the citizen has an existing relationship with the government agency. If it exists, the Gov RP should have the ability to use some shared private information as a starting point to establish the link between a citizen's (credential) identifier (obtained from the credential verifier) and the PID. e.g. Driver's License Number (DL#) if visiting the Motor Vehicle Administration (MVA) or Social Security Number if visiting the Social Security Administration.

It is important to note that this information is already known to the RP, used only as a claim of identity by the citizen, and providing just this information does not constitute proof of identity. i.e. When I provide my DL# to the MVA, I am saying that "Here is DL# XX-XXXXXXX; I claim that I am the Anil John you have on record as being the owner of that DL#". Before enrollment, the MVA would still need to verify that it is indeed me making this claim using an identity proofing process, and not an identity thief who has obtained my DL#.

So for enrollment to work, the RP needs two sets of data:

1. A shared private piece of data that represents a claim of identity by the citizen
2. A set of information that can be used to prove that claim to the satisfaction of the RP

If the identity verification is successful, the RP can establish a link the between credential identifier (OpenID PPID, SAML NameID, X.509 SubjectDN etc.) and the PID.

In cases where shared private information does not exist between the citizen and the agency, some options to consider are:

1. In-person identity proofing
2. Attestation from a trusted third-party
3. Shared service for enrollment across multiple RPs (Privacy implications would have to be carefully worked through)
4. No linking possible; treat as new record

Are there variations or additions to this step that I have not captured above?

RELATED POSTS

• How to Verify Citizen Identity Easily and Effectively
• Assurance Level Escalation and Government Relying Parties
• How To Collect and Deliver Attributes to a Relying Party for User Enrollment

:- by Anil John

How to Verify Citizen Identity Easily and Effectively

Identity verification of citizens is critical to delivering high value government services online. Differing approaches to identity verification include front-end identification, which fits well with existing Government trust models, and back-end identification, based on widely deployed commercial practices. This blog post describes these two common models and the approach and trade-offs associated with each.

One of the reasons for trying to articulate this is that I have found myself recently in multiple settings discussing protocol flows and privacy preserving crypto.  But at the end of the discussion, I often feel as though we have not asked ourselves some foundational questions regarding choices made in identity proofing and credential issuance.  This in turn has resulted in a lack of clarity around the downstream impact of those choices on privacy, security and flexibility. So here goes...

 

The Front-End Identification is the same as the E-Authentication model that is found in NIST SP-800-63-1 (PDF). It follows the sequence of:

1. Person Registration/Identification
2. Binding of Identity and Token
3. Credential Registration/Issuance
4. Person Enrollment at Relying Party

Approach

Trade-Offs

Identity proofing is done up front by a credential provider with registration function or using a separate registration authority Credential incorporates assurances of identity User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]

Ability to leverage results of identity proofing across multiple relying parties RPs limited to approved credentials that meet assurance criteria May be harder to utilize a higher LOA credential in transactions that support anonymity and pseudonymity without "beautiful math" or other proxy mechanisms

 

The Back-End Identification is the E-Authentication model that is found widely deployed in the commercial space. It follows the sequence of:

1. Credential Registration/Issuance
2. Person Registration/Identification
3. Binding of Identity and Token at Relying Party
4. Person Enrollment at Relying Party

Approach

Trade-Offs

Credential is often little more than a token (i.e. shared secret) and may have little to no assurances of identity Identity proofing done directly by the RP or by using a separate proofing capability to the level required by policy User enrollment at RP based on information available from the identity proofing process and/or other sources [Enrollment is defined here as the creation of an association between the person's identifier and the index for the person within the RP application]

Any token and/or combination of tokens can be used depending on the “technical strength” needed Proofing process can be as stringent as need be, so the information in credential can be as anonymous or revealing as need be Inability to leverage identity proofing across multiple RPs

 

Have I accurately captured the two major approaches in play right now? Are there trade-offs that you can think of that should be added to the lists above? 

 

UPDATED: 12/1/2012 with clarifying text and pictures re: where the token-identity binding takes place

 

RELATED POSTS

• Assurance Level Escalation and Government Relying Parties
• If You Don't Plan For User Enrollment Now, You'll Hate Federation Later
• How To Collect and Deliver Attributes to a Relying Party for User Enrollment

:- by Anil John

FICAM Trust Framework Solutions - A Primer

It is in the Government's best interest to not re-invent the wheel and leverage Industry resources whenever possible. To support E-Government activities, FICAM aims to leverage industry-based credentials that citizens already have for other purposes. At the same time, the Government has specific Privacy and Security requirements that need to be satisfied in order for a Government relying party to trust a credential that has been issued by an entity other than the US Federal Government.

The approach used to assess external (to the US Federal Government) credential issuance processes against these privacy and security requirements is called the FICAM Trust Framework Solutions:

As you can see in the diagram above, the entities in this mix are a Trust Framework Provider, one or more Identity Providers (IdPs), and FICAM.

• A Trust Framework Provider (TFP) is an entity, separate from the Federal Government, that has a certain level of organizational maturity and owns/manages/has a mechanism to assess credentialing process across a range of facets that include assurance, privacy as well as auditing & certification processes using qualified independent auditors i.e. it owns and is responsible for a Trust Framework.
• The Trust Framework Provider in turn has the capability to assess Identity Providers to see if the IdP has a certain level of organizational maturity and if its registration & identity proofing processes, credentials,  credential issuance processes and privacy policies meet the policies codified under the TFP's Trust Framework.
• Where FICAM comes into the picture is via using our Trust Framework Adoption Process (PDF) in order to "adopt" an existing Industry Trust Framework. What that means is that we use the adoption process to see if the requirements of the Trust Framework we are using internally within the Government are comparable to the existing Industry Trust Framework. I especially want to emphasize that the intent here is comparability and NOT compliance. If they are indeed comparable, we adopt and certify that industry Trust Framework Provider, and customers of Identity Providers who have been assessed and approved by that TFP can now use those credentials at TFP-enabled Federal Government relying parties.

It is important to call out some specific points:

• Trust Framework Providers are NOT Identity Providers
• Trust Framework Providers assess IdPs for conformance against their Trust Framework and not the Government Trust Framework
• The Government does not directly certify Identity Providers under the Trust Framework Solutions Process; The Government directly certifies ("adopts") Trust Framework Providers

It is critical to note that the Level of Assurance (LOA) you can have in an Identity is a big deal to the US Federal Government, and as you go to higher LOAs (from 1 to 4) the more stringent the credential issuance and identity proofing processes become.  As such, TFPs and their Trust Frameworks need to have comparable processes to the Government Trust Framework at higher LOAs in order for them to be able to assess IdPs as being able to issue higher LOA credentials.  In some cases, a TFP may make a conscious choice that they will assess only IdPs at specific LOA levels.

Let me, at this point in time, add a bit of nuance to this process. The Government E-Authentication Model provides for a logical and physical separation between the Registration/Identity-Proofing function and the Token and Credential Registration/Issuance function. In the IdP model noted above those functions are shown together. They do not have to be. It is perfectly feasible under the Trust Framework Solutions Model to have separate entities doing the Identity Proofing and the Credential Issuance, and coming together to provide a combined solution that can be certified by a TFP. Simply be aware that under the current FICAM TFP regime the term "FICAM Approved" applies to that combined solution and NOT to the individual components.

Since October 2011, there has been an OMB Policy that requires Government web sites that allow members of the public and business partners to register or log on, to be enabled to accept externally-issued credentials (i.e. credentials issued by an entity other than the US Federal Government) in accordance with government-wide requirements (PDF). The Trust Framework Solutions Process satisfies that requirement by enabling a scalable model for extending identity assurance across a broad range of citizen and business needs.

Related Information

• Current List of FICAM Approved/Adopted Trust Framework Providers
• Current List of Identity Providers who have been assessed and certified by their respective TFPs
  NOTE: Strictly speaking there is no "FICAM Approved IdP". That terminology is more of a short-cut to describe an IdP that has been approved in turn by a "FICAM Approved/Adopted Trust Framework Provider"
• OMB Requirements for Accepting Externally-Issued Identity Credentials [PDF]
• Trust Framework Provider Adoption Process [PDF]
• Privacy Guidance for Trust Framework Assessors and Auditors [PDF]
• NIST SP-800-63-1 E-Authentication Model

:- by Anil John

Electronic Authentication, Mobility and Mistakes

Over at Gartner, Mark Diodati had a recent blog post regarding issues that are surfacing as part of Gartner's research into Mobility. Two particular items in the blog post caught my eye:

"Many organizations make the classic distribution mistake; they couple a weak identity proofing mechanism with the deployment of stronger authentication systems"

"I have seen many organizations try to fix the identity proofing problem after deployment because they have little confidence that the OTP secrets are in the hands of authorized users." 

This brought to mind some discussions that I've been part of regarding the use of tokens at varying levels of assurance and assurance level escalation mechanisms.

Whenever you start down this path, it is often worthwhile to step back and look at the Registration, Credential Issuance and Maintenance sections of the Electronic Authentication Model (from NIST SP-800-63-1 PDF):

As you can see above, you have an Applicant that registers with a Registration Authority (RA), which identity proofs the Applicant and confirms the results of that event with a Credential Service Provider (CSP). The CSP in turn interacts with the Applicant to issue a Credential that binds the identity of the person to a Token (a secret, or something that holds a secret used in a remote authentication protocol). At this point in time the Applicant becomes a Subscriber of the CSP. The rest of the model focuses on the use of the credential and token.

While the RA and CSP functions, especially in the commercial world, are often done by the same entity, the key point to keep in mind is that Registration, Identity Proofing, Token Creation/Issuance and Credential Issuance are all distinct and logically separate processes that can be broken up into separate physical encounters or online/electronic transactions. Point of fact, they could be broken up and fulfilled by entirely separate entities. The challenge in this, as noted in Mark's blog entry, is to make sure that the same party is acting as the Applicant through the process.

A model to look at and potentially implement [1] that may help in this area is what we use within the US Government for credential issuance  at Level of Assurance (LOA 1 - 4). We have increasingly stringent requirements (as we move from Level 1 to 4) that we need to follow in order to make sure that the same Applicant is moving through the process (More details in NIST 800-63-1):

• At Level 1: There is no specific requirement, however some effort should be made to uniquely identify and track applications.
• At Level 2: For electronic transactions, the Applicant shall identify himself/herself in any new transaction (beyond the first transaction or encounter) by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s phone number, email address, or physical address of record.
• At Level 3: For electronic transactions, the Applicant shall identify himself/herself in each new electronic transaction by presenting a temporary secret which was established during a prior transaction or encounter, or sent to the Applicant’s physical address of record. Permanent secrets shall only be issued to the applicant within a protected session.
• At Level 4: Only physical transactions apply. 

Ultimately, whatever types of credentials you are issuing, and in whatever modalities that credential is being used, if you cannot have confidence in the processes used to assure that the person using the credential is indeed the person that went through the above steps to get the credential, then you have gained little to no value by choosing to issue a technically "stronger" credential type.

[1] For those reading this from USG Agencies: The choice to implement or not does not exist for us :-). OMB Policy on Annual FISMA Guidance M-11-33 (PDF) makes implementation of NIST Guidance a requirement.

:- by Anil John