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. 
The fundamental reason for lack of commercial IDP engagement is that the government requirements for high assurance credentials 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 but in most cases are only protected by password authentication and use nothing more than session-based protections. 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 (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; 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.
 This list is an overly optimistic statement of the IDPs currently certified for FICAM use
 Often these emerge from a strict security motivated view of identity
 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
 Lots of crypto protects the transactions themselves, but that is distinct from the Identity assurance and credential considerations