The business case for Identity providers (part 1)

In the Netherlands the government provides a reusable digital identity, DigiD, to it's citizens. DigiD can be used for different G-C transactions, for tax-return forms, getting certain licenses from local government, communicating with healt insurance companies and pension funds. The uses are strictly defined by law, you can't use DigiD for commercial transaction, like webshops or for other transaction. And DigiD can only be used in the Netherlands, not abroad. There is another 'minor' problem with DigiD: any Dutch citizen can request a DigiD and the DigiD Identity Provider (IdP) sends an activation code by snail-mail. Not the most secure way of identity provisioning and there have been some incidents of criminals fishing the activation letters from the mailbox. And if a criminal first requested a DigiD on behalf of a victim, of course he knows when to lookout for the mail to capture it…

Anyway the Dutch government is in the process of building a new identity framework, thereby making it possible for third parties to act as an identity provider within the Dutch eID framework.

In a series of blogposts (Dutch: First post and second one) I asked myself the question: is there a business case to become an IdP? Is there any commercial driver to become an IdP? Or are there other drivers?

I found out that it is very hard to answer these questions positively…

A few years ago I was at the European Identity conference in Munich and on one of the panels Kim Cameron remarked that everyone wants to be an IdP. If consumers use your Identity, the single fact that people use one your Identities creates a brand value. You grow a valuable reputation.

But if everyone becomes an IdP, what does that mean? Can you use and reuse every one of those identities? That makes for an interesting problem: at this moment noone wants to accept just any third party digital identities. The reuse capability is very small, too small to make people use a third party identity. We have a deadlock situation. Why is that?

Of course some identities can be reused. Think about Facebook, Twitter and LinkedIn identities. These can be reused, but just to a certain extent. These (free) identites are only trusted by service providers if there's something in for them... For a service provider these identities make it possible to have an authenticated account, without the need to store and protect identity information, like passwords. You can't lose what you don't have. So accepting third party identities is not only useful for consumers, but even more for SP's, as some kind of preventive privacy control against data leakage. But no service provider will let you make financial transactions using a facebook account. Facebook (as a service provider) may do so, but independent third parties will be very reluctant.

Why is the reuse capability of third party identities limited?

Well, in my opinion it's the lack of a transparant, and trusted, Trust Framework.

A few years ago we tried to create a Trust Framework based on the OpenID standard, we called it OpenID+. The + being the Trust Framework. The group that worked to create OpenID+ consisted of a government body, a few financial corporations, some ebusiness companies, media corporations, all prominently present on the Dutch internet space. Interestingly both IdP's and SP's took part in the development of the trust framework. The main principle being that any OpenID+ SP would have to accept any identty that was provided by any OpenID+ IdP!

We started building the policies and procedures, in our spare time (I know, I was one of the authors) and when we deemed the framework sufficiently mauture, we decided to go ahead and to start a few OpenID+ proofs of concept. In order to build the trust framework, we defined the technical extentions for OpenID, the policies for the identity provisioning processes, for deprovisioning, for auditing and legal issues. These were some of the questions that had to be answered in order to create the trust framework:

• Should we create a (secure and trusted) white list of trustworthy OpenID+ IdP's?
• How should an OpenID provider apply for the white list?
• Should there be an audit guideline for audit or self-assessment?
• Can any service provider access the white list, or should we allow only connected OpenID+ service providers?
• How could we guarantee that all providers would interprete claims and attributes in the correct manner?
• What should happen if an incident occurs? For instance in case of misuse or theft of an OpenID+ identity, or wrong interpretation of an attribute of an OpenID+ identity by a service provider?
• How about liability in case of an incident?
• How long should a white list entry be valid?
• Would we need an arbitration committee?

Quite a lot of question, and this was only a small number of questions. And that was when trouble started. Defining the standards was okay, but implementing the standards proved very difficult. We found out that building such a trust framework was very expensive. Especially the documenting and auditing of the processes and techniques proved so costly, that the parties became afraid for what would come next. Who should pay the costs of such a trust framework?

As a result the OpenID+ framework was never implemented. There was no positive business case for any of the participants.

That's not the end of it. Yet. There are several financial models for IdP's. In my next post I will introduce different models and expend on the business case for Identity Providers. And I will try to explain why the reuse capability of digital identities is critical for the succes of IdP's.