Challenges in Operationalizing Privacy in Identity Federations - Part 3

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

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

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

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

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

The RP then initiates the attribute verification process:

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

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

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

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

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

RELATED POSTS

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

:- by Anil John

What are FICAM Technical Profiles and Identity Schemes?

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

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

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

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

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

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

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

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

We expect this to continue and expand in the future.

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

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

RELATED INFORMATION

• FICAM Technical Profiles and Identity Schemes

:- by Anil John

How To Implement the Technical Aspects of an Identity Oracle

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

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

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

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

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

A potential technical interaction between the three entities could be:

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

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

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



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

RELATED POSTS

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

:- by Anil John

Attributes Anytime, Anywhere. Extending BAE to Support New Protocols

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



XACML

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

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

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

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

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

OAUTH 2

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

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

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

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

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

Comments and perspectives on both are welcome!

RELATED POSTS

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

:- by Anil John

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

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

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



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

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

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

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


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



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

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

RELATED POSTS

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

:- by Anil John

What is new with the BAE Operational Deployment?

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

The operational scenario looks like this:


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

RELATED POSTS

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

:- by Anil John

RFI/RFP Language for Federation Solutions and Identity Proofing Solutions

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

Identity Federation Solution for Agency as Relying Party

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

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

Identity Proofing Service

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

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

Do keep in mind the following:

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

RELATED POSTS

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

:- by Anil John

Shared Services and Government as Attribute Service Provider

FICAM Roadmap and Implementation Guide articulates the need to provide government-wide services for common ICAM requirements. In addition, an execution priority for FICAM is to demonstrate the value of policy driven access control in Government systems.  One of the ways that we are moving forward in this area is by piloting the operational use of attribute services, backed by attribute providers, that can act as a single point of query for relying parties.

What is an attribute provider (AP)?

The National Strategy for Trusted Identities in Cyberspace (PDF) describes an AP as being "... responsible for the processes associated with establishing and maintaining identity attributes. Attribute maintenance includes validating, updating, and revoking the attribute claim. An attribute provider asserts trusted, validated attribute claims in response to attribute requests from relying parties."

Why is this important?

• We are moving into an era where dynamic, contextual, policy driven mechanisms are needed to make real time access control decisions at the moment of need.
• The policy driven nature of the decisions require that the decision making capability be externalized from systems/applications/services and not be embedded within, and that policy be treated as a first class citizen.
• The input to these decisions are based on information about the subject, information about the resource, and contextual information that are often expressed as attributes.
• These attributes can reside in multiple sources where the level of confidence a relying party can have in an attribute may vary and has many components (Working on this one).
• The relevant attributes are retrieved (“pulled”) from the variety of sources at the moment when a subject needs to access a system and are not pre-provisioned into the system.
• Standards! Standards! Standards! All of the moving parts here (finding/correlating attributes, movement of attributes across organizational boundaries, decision control mechanisms etc.) needs to be using standards based interfaces and technologies.

How will this capability be implemented?

As a first step, we are partnering with PM-ISE on an operational pilot (real missions, real data, real systems, real users) of the FICAM Backend Attribute Exchange (BAE) capability.

The BAE capability provides a "... standards-based architecture and interface specification to securely obtain attributes of subjects from authoritative sources in order to make access control decisions."

If interested in its technical details, do check out the final version of the BAE v2 technical documentation set:

• BAE v2.0 Overview
• SAML 2.0 Identifier & Protocol Profiles for BAE v2.0
• SAML 2.0 Metadata Profile for BAE v2.0
• BAE v2.0 Governance

As someone who has been involved with the BAE since the first prototype, it is interesting for me to look back on the timeline for how we got here [Full Disclosure: Some of the links below point to blog entries from before I entered Federal Government Service; At that time, I was a Contractor supporting the DHS Science & Technology Directorate as the Technical Lead for their Identity Management Testbed]

• [2009] Prototype implementation of the BAE architecture between DHS S&T and DOD DMDC West. Focus was just on PIV/CAC driven attribute retrieval
• [2009 - Present] Ongoing, and successful, work with vendors to "bake-in" support for BAE Protocol Profiles into their products
• [2010] End-to-end proof-of-concept implementation (synthetic data) between DHS (S&T/FEMA/HSIN/OCIO) and DOD (NORTHCOM/NSA/DISA) that demonstrated the real-time ABAC capabilities possible by implementing a "pull-based" identity and access control architecture using the BAE. Expanded specification to accommodate non-smartcard driven attribute retrieval use cases
• [2010] DHS S&T submitted lessons learned and outputs of prototypes and pilots to FICAM to make it part of the FICAM work stream
• [2011] Partnership between FICAM and DHS S&T to stand up a Reference Implementation of BAE v2 in the DHS S&T Identity Management Testbed 
• [2011] FICAM Stands up the E-Government Trust Services (EGTS) CA capable of issuing NPE  certificates to BAE Compliant Attribute Services
• [2012 - January] Final version of the BAE v2 specification is released (also directly linked to above) which includes support for privacy/consent-based attribute release 
• [Now] We are moving out ...

RELATED POSTS

• From AAES to BAE - Implementing Collection and Sharing of Identity Data
• What is new with the BAE Operational Deployment?

:- by Anil John