One of the interesting aspects of the component identity services model as outlined in Section 3.2 of the FICAM TFS Trust Framework Provider Adoption Process for All Levels of Assurance (PDF) are the roles, responsibilities and expectations of each of the components. This is especially critical within the context of identity federation when you are depending upon entities outside your security/business domain for critical identity capabilities.
BTW, I find the commonly used term identity provider, at best, imprecise and, at worst, misleading since as typically implemented they are often not one or the other. So let me start with some standard terminology from OMB M-04-04 E-Authentication Guidance for Federal Agencies (PDF) and NIST Electronic Authentication Guideline SP-800-63-2 (PDF):
- Identity: A set of attributes that uniquely describes a person within a given context
- Token: Something that the Claimant possesses and controls (typically a cryptographic module or password) that is used to authenticate the Claimant's identity
- Individual Authentication: The process of establishing an understood level of confidence that an identifier refers to a specific individual
- Level of Assurance (a.k.a Assurance Level of a Credential): Defined as (1) the degree of confidence in the vetting process used to establish the identity of an individual to whom the credential was issued, and (2) the degree of confidence that the individual who uses the credential is the individual to whom the credential was issued
All of this works brilliantly and seamlessly when the vetting and the secure binding of the identity to a token, and the assertion of that identity to a RP is done within a single security/business domain. The Relying Parties (RPs) within that domain have full access to the identifier as well as the set of attributes that uniquely describes a person.
The pieces get much more distributed within the context of a Federation.
First and foremost, the starting point of identity within a federation, in the majority of public sector online service use cases, is entirely driven by the need to uniquely describe a person to an RP so that someone from outside the RP's security/business domain can be mapped into the RP in order to deliver online services to them.
The assertion of an identifier by a CSP is not enough to resolve that person to a unique individual, especially within the US context where there is no single mandated identity-card/identifier that can used by the RP to "look up" the identity (i.e. the set of attributes that uniquely describes a person) for resolution.
Identity in a federation is ultimately in the eye of the RP, so a CSP that is able to convey nothing more than an identifier is not providing enough information to the RP to allow it to do identity resolution. And while they may indeed play the role of a CSP within an Enterprise/White-label-scenario or a single security/business domain, without the ability to provide identity attributes that allow for resolution in a federation environment, they are asserting a Token and not a Credential i.e. They are a Token Manager.
In a recent blog post, Does KBA and Public Sector Online Services Have a Future?, I raised as an issue the inadequacy of KBA for remote identity proofing given the public, and potentially compromised, data sets that are currently used for this purpose. I believe that it is critical for citizen facing public sector services to incorporate continuous identity vetting/verification/proofing as a compensating control. But can that be effectively done when the service is utilizing federated credentials?
The current notion of having layered security controls is often focused on the network, host, and application layers (which are absolutely critical) and less so on having layered controls within the authentication process itself. For citizen and business facing public sector services, I believe that the strong processes outlined in NIST Electronic Authentication Guideline SP-800-63-2 (PDF) should only be one layer in a comprehensive authentication strategy.
But when adding compensating controls to a federation environment, the following questions come to mind:
- What guidance can serve as a starting point?
- What technical controls are recommended?
- Which entity in a federation is ideally suitable (or capable) of implementing specific controls?
I have found the Federal Financial Institutions Examination Council (FFIEC) authentication guidance (PDF) a good resource on this topic. It identifies the following Technical Controls:
- Out-of-band identity verification (via a separate channel) to pass through gates related to account maintenance activities (e.g. password reset) performed by customers either online or through customer service channels
- Device Fingerprinting (including device configuration, IP address, geolocation) with the initial binding of the fingerprint to a user done by leveraging an out-of-band identity verification mechanism
- Internet protocol (IP) reputation-based tools to block connection to servers from IP addresses known or suspected to be associated with fraudulent activities
- "Out of Wallet" questions that do not rely on public information (i.e. the entity has a close relationship with the person and can leverage internal data for this purpose) for authorizing higher risk transactions
- Anomaly detection that looks at velocity of transactions as well as customer history and behavior
In the above table, I've also taken an initial cut at mapping the controls to the entities able to implement them (based on policy) in a federation environment.
The answer to the question that I've asked as the title of the blog post is "YES". It does require clear thinking on roles, responsibilities and capabilities, but in order to effectively deliver public sector online services, we need to move away from the waterfall approach to identity proofing that is in place to one that is more agile and responsive to the constantly morphing threats.
I've written before about Multi-Sided Platforms and how it provides a model for looking at identity federation. Given that public sector organizations across the world are starting to deploy such platforms (brokers, exchanges, hubs etc), this blog post looks at some potential capabilities that could be enabled by such platforms.
I won't belabor the benefits of minimizing integration pains, enabling protocol mediation and privacy respecting capabilities. They are all critical, but well understood, aspects of why the public sector is going with the Platform-in-the-Middle approach to leveraging non-public sector identity services.
In this post, I would like to focus on two things that have great impact on the adoption of identity federation in the public sector; Culture and Contracts.
Public sector agencies vary in their understanding of identity, and their mission and the nature of their relationship with the citizen often drive that understanding. You will often find a deep and nuanced view of identity, risk and fraud in agencies that maintain a citizen's vital records. As I have noted before, these are the agencies that often have a role in identity establishment.
These agencies believe (and rightfully so) that their internal capabilities for identity proofing are more trustworthy than anything found in the private sector. I personally don't believe in force-feeding these agencies CSPs or Identity Managers. But they may very well find Token Managers, offered via a Platform-in-the-Middle to be an attractive option. It allows them to control the identity proofing and the secure binding to the token. The reverse case is an Agency that has a mature Token Management infrastructure and wants to leverage external Identity Managers.
On the contracting side, using the Platform as the point of demand aggregation to drive pricing negotiations for the services, improves choices while enabling a flexible pricing model based on needed capabilities.
In short, the key to using the platform for identity federation adoption is to have options available, buffet-style, tailored to Agency needs and culture and not a one size fits all solution.
On this blog, I try very hard to keep my (Passions+Interests+Career) separate from (The Job). Since I often discuss digital security, privacy and architecture within the context of public sector service delivery, which fall into the former category, I would be remiss if I did not mention the update by the U.S. Federal Government to it's Identity Federation Framework.
But since this particular topic does bleed over into the latter category, I will simply stop here with pointers to the public information on it. Go read, react, engage!
The FICAM Trust Framework Solutions (TFS) is the federated identity framework for the U.S. federal government. It includes guidance, processes and supporting infrastructure to enable secure and streamlined citizen and business facing online service delivery.
For the first time since the inception of the Program in 2009, we are releasing a comprehensive update to the Program to incorporate Agency implementation feedback, ongoing lessons learned regarding the operational needs of shared service initiatives such as the Federal Cloud Credential Exchange (FCCX), as well as updates made as a result of changes in the private sector marketplace of identity services.
FICAM Trust Framework Solutions Program
Public sector services typically prioritize policy compliance (security, assurance, privacy etc.) over user experience (UX) when it comes to service delivery. Contrast this with private sector services where the desire to capture the consumer and not have them go to a competitor drives the decision to make the UX friction-free a higher priority. Effective public sector service delivery requires a balance between these two extremes but expertise and experience in this domain is either lacking or hard to come by.
If there is one lesson from the HealthCare.gov rollout that needs to be taken to heart by the public sector, it is to blow out of the water the notion that in a service with no competitors, users are a captive audience and as such UX is a low priority item.
The analysis done by the Nielsen Norman Group should be eye-opening, especially when it comes to account setup (user enrollment):
Account setup is users’ first taste of a service. A suboptimal account setup can spawn 3 problems:
HealthCare.gov’s Account Setup: 10 Broken Usability Guidelines
- Increased service cost: When people can’t self-service online and you have no competitors, they call you. Call-center interaction is more expensive than web self-service. In 2008, Forrester estimated call-center calls to cost $5.50 per call versus 10 cents for a user who self-services online.
- Increased cognitive strain: The instructions for creating usernames and password in this flow [...] require a great deal of concentration, and if users don’t understand the instructions, they will need to keep creating usernames and passwords until they are accepted.
- Halo Effect: Account setup is the first in a series of web-based interactions that users will need to conduct [...]. A poor experience with this first step will impact how people feel not only about subsequent interactions with the site, but how they feel about the service in general [...]
The challenge in this space is that there are very few organizations, who have high assurance needs, that are doing user experience and usability testing. One such is the UK GDS Identity Assurance Program, which has published some of their research:
- most people we encounter have no prior experience of using a third party company to identify them
- if they have used a third party to sign in it’s most likely to be via a social media account, and most people we’ve met tend to avoid using their social media account to sign in to other services
- [The UK Program to use commercial CSPs at Gov web sites] will often be the first time people use this model and they need to be assured that it is a legitimate process
UK GDS IDAP - User Research
But do the UK results apply across jurisdictional and cultural boundaries? I don't know, but believe that it is imperative that there be localized answers. My fear is that we are not investing enough in this area, and that lack of investment will come back to haunt us down the line.
As I've pointed out before, the user enrollment aspects of how high assurance credentials are currently envisaged to be provisioned to regular users (people not familiar with identity) flies in the face of the adoption mantra that "Disruptive innovation should be non-disruptive to adopt". That needs to change.
Identity is the starting point for most public sector business processes that touch citizens. Only when identity has been established do all subsequent public sector online activities, ranging from transactional services to benefits delivery proceed.
In a magical world, these are the three wishes I would ask for from the public sector identity genie, in order to deliver more effective online services:
1) Make Metrics Matter If you are not measuring the right things, you have no idea when you are doing well or doing poorly.
- What are the top 10 transactions that a citizen conducts with the public sector?
- What is the cost/transaction? How much of that cost is identity related?
- Justify with data the choice of internal identity implementation vs. shared services
2) Enable Expertise Build, within government, highly skilled multi-disciplinary technical and policy expertise that can be used, across Agencies, to deliver critical public sector services.
- Highlight the really interesting problems that need solutions; that attracts the best
- Build the A-Team because it is important and it matters
- Encourage long term commitment to public service rather than short term stints
3) Share Solutions Create a cross-jurisdiction Identity Assurance Federal Advisory Committee to tackle the intersection of citizen benefits delivery, fraud and identity
- Benefits delivery and fraud cross jurisdictional boundaries; solutions need to cross them as well
- Leverage the expertise from federal, state, local, tribal jurisdictions and industry sectors
- Commitment to openly sharing solutions