Tag Archives: NSTIC

Meeting an Immovable Object The Economics of Consumer Identity Providers

Uncle_Sam_(pointing_finger)
Your Government Needs Your Consumer Identity Provider

In many parts of the world, Governments have been trying to engage industry IDPs to provide consumer identities to support government & citizen service requirements. In cases such as the US FICAM these results have at best been marginal. [1]

The fundamental reason for lack of commercial IDP engagement is that the government requirements for high assurance credentials[2] leads to expensive identities that are not required for most commercial or enterprise usage. It is not economically interesting to IDPs to invest in creating identities that are designed for unique government requirements.

The motivations for wishing to engage commercial IDPs are essentially sound…

Large scale Consumer Identity Providers have hundreds of millions of consumers that use services that in turn trust the IDP. Consumers IDPs address many issues with friction and the user experience pain associate with occasional usage; large IDPs generally have a significant investment in professional organizations to handle the authentication, identity management, account recovery and risk analysis that cannot be matched by most service providers, including governments. While they are far from perfect IDPs represent a significant center of expertise that have demonstrated identity operation at Internet and International scale.

However, the “assurance” required for in practice for most commercial transactions barely equates to a NIST Level of Assurance (LOA) 2 Identity.

PayPal successfully utilizes its identities for financial transactions (higher assurance requirements than most commercial transactions). These identities have good identity validation[3] but in most cases are only protected by password authentication and use nothing more than session-based protections[4]. The assurance level model hides the fact that high quality identity assurance is being performed, and worse in a formal evaluation would prohibit the identities from being used for financial transactions.

This demonstrates a dilemma. The formal assurance level criteria do not seem to match real world identity usage.

The disparity between the current assurance models and actual usage poses a problem. Governments have been trying to convince commercial IDPs to jump on board and supply the identities they need. In a perfect world, the formal identity assurance specifications might be seen as an aspirational opportunity, that an enlightened world might choose to adopt.

Why would a Google, or a Facebook or a LinkedIn or a Twitter choose to add significant additional cost across hundreds of millions of users in order to meet standards such as those defined by NIST?  It takes only simple math to calculate the cost of a multi-factor authentication solution, or LOA 3 Identity when it is applied across six hundred million consumers…

Commercial IDPs are definitely interested assisting their users to utilize their identities (or at least their authentication credentials) across a broad and growing set of services. This is the basis for recent technology innovations including OpenID Connect, OAuth and Account Chooser. However, the characteristics of the identities supported by IDPs do not correspond to what governments are requiring (hoping for?).

However, vague promises of future revenue considered against a backdrop of significant government and community scrutiny and brand risk, in addition to the high costs of creating LOA 3 identities for government, the additional capabilities that have to be included and the liabilities incurred do not constitute a reasonable business opportunity.

There are ways out of this impasse. But they require different system architectures and operating principles to the ones commercial entities are being asked to comply with.

Several fundamental approaches have merit: Risk Based Identity Evaluation and Mitigation; Separation of Identity Services; Identity Assurance Enhancement (like “step up authentication”); User Pays models.

PayPal’s “low assurance” identities work . However, the characteristics of the identities supported by IDPs do not correspond to what governments are requiring (hoping for?).

However, vague promises of future revenue considered against a backdrop of significant government and community scrutiny and brand risk, in addition to the high costs of creating LOA 3 identities for government, the additional capabilities that have to be included and the liabilities incurred do not constitute a reasonable business opportunity.

There are ways out of this impasse. But they require different system architectures and operating principles to the ones commercial entities are being asked to comply with.

Several fundamental approaches have merit: Risk Based Identity Evaluation and Mitigation; Separation of Identity Services; Identity Assurance Enhancement (like “step up authentication”); User Pays models.

PayPal’s “low assurance” identities work (hundreds of millions of dollars of financial transactions are successfully executed daily) because they have implemented effective risk evaluation models and compensating controls that mitigate potential issues.  Current Identity Assurance models assume that identities can be absolutely evaluated and defined. This is clearly nonsense – all identity validation systems provide at best a confidence level (often lower than we would like to believe) on the identities that are being asserted. We need models that clearly support such approaches and recommend how to mitigate corresponding risks.

Reassessing where identity services are delivered and allowing disaggregation of existing architectures would help in several government contexts. Allowing IDPs to simply assert an authentication event and deliver a credential would eliminate the need to invest in identity validation services at the IDPs, and potentially open up new business opportunities, or at least allow the gap in existing service capabilities to be addressed.

Identity assurance enhancement assumes that consumer IDPs will provide what is commercially viable, and then some other entity must enhance them so they have characteristics in keeping with desires of the services that will use them. Enhancement may take the form of a service; it may be offered on a per relying party basis or as a central function supporting many service users[5]; it may be created by government, alternatively some commercial entity may see a business opportunity and offer it as a service to government.

The user pays model goes hand in hand with the identity assurance enhancement model. If IDPs do not see value in providing higher assurance identities but government needs it, then government should pay for the enhancement, Instead of trying to convince an IDP to upgrade its general user population, pay for enhanced assurance levels as they are needed. This allows existing commercial entities an opportunity to leverage their validation techniques.

In the near term, a more realistic expression of assurance levels would be a start. I have been arguing for many years now that the simplistic evaluation of a scalar assurance level makes no sense (especially in a world where we are dealing with confidence levels on the outcomes anyway). Minimally, we need a few more finer grain assurance levels that actually map current usage?

Ideally we should move to a model that allows the collection of evaluation criteria to be reported so we can do the risk evaluation and work out which identities we can apply mitigation strategies to (a course that is not possible if we have eliminated all the information in a reductionist process).

The very short term approach will almost certainly be to accept that IDPs will create identities with an assurance level that makes business sense – a one or two may even try to create high assurance identities – bight the bullet and use the ones that are available, at the assurance level they are available at. If other identities with other assurance levels are required then let’s role up our sleeves and work out how to how to enhance them, who can do the work, and how to pay them.


[1] This list is an overly optimistic statement of the IDPs currently certified for FICAM use

[2] Often these emerge from a strict security motivated view of identity

[3] Like any other financial services provider, this requires compliance with Know Your Customer (KYC) rules, Anti Money Laundering (AML) requirements and a stack of others

[4] Lots of crypto protects the transactions themselves, but that is distinct from the Identity assurance and credential considerations

[5] The Federal Cloud Credential Exchange (FCCX) is an example of where enhancement services might be implemented or integrated.

Is there a Relying Party in the [White] House?

I was up on whitehouse.gov this morning signing up for a petition. Going through the normal account registration processes, I was looking in vain for the “login with Facebook” or “login with Google” buttons.

I am sure this version of the identity system for the web site has been in place for some time, but what happened to the dreams of utilizing OpenID (or more appropriately OpenID Connect) as the basis for registering and authenticating users to this site?

whitehouse.gov is a trivial relying party from an identity perspective. The information requested is all self asserted. The only item an IDP (OP in this case) might not be able to assert is the zip code.

Four years ago at the behest of White House, I and a few other intrepid souls (I, in the guise of PayPal), set up several LOA1 IDPs with the express goal of supporting citizen access to this site – it was a high risk engagement for me and others at PayPal personally at that time and had its own internal implications.

whitehouse.gov was certainly using OpenID at one point, so they obviously backed it out at some later point.

I feel a little like American occupied countries that are promised a long future of support only to find out the USA got bored 12 months later.

We are fast coming up on the next IDESG meetings in Phoenix. Here is the question for NSTIC and the White House. “If a low risk web site operated by Valium 15mg the Valium 15mg White House is failing to use the most fundamental identity technologies (or worse has turned them off), why should the rest of the USA conclude that it is worth taking any action to implement this identity stuff?” This is a terrible reference for the NSTIC program.

Over the years there have been numerous meetings at the White House leading up to the formation of NSTIC and the IDESG. In those meetings several of us made the plea that apart from all of the multitudinous complexities the NSTIC program could address, if we simply had help engaging with RPs then we could advance the cause and adoption of trusted identities and transactions.

Four year later, we have not made any progress with RPs. Instead we have a governance structure that rivals that of a small nation in complexity (though to be fair though I have always favored an LDAP over X.500 approach. :) ) and are just settling down to debate the big questions – none of which may be worth the proverbial hill of beans.

Once you clear away all the privacy issues, the rules of engagement, the sectarian interests and all of our hopes, the most important question still appears to be unanswered…

“Can we provide value to RPs that they will pay for?”

If the answer is yes, a lot of issues will be worked out in the process of growing that ecosystem. If the answer is no, then NTSIC and the associated efforts are largely a waste of time.