Digital identity in the Netherlands: DigiD for consumer-2-business?


On Tuesday 4 October we organised a Novay networking event called Tuesday Update, with digital identities as the subject. The main subject of discussion was the need for re-usable identities, and especially who should be the identity provider: government or private parties. This is a hot subject in the Netherlands, also because of the recent security incidents (DigiNotar). Hein Aanstoot, director at SIVI, argued very well that the insurance sector increasingly needs a consumer-2-business identity solution, and would they be allowed to use the national citizin-2-government solution DigiD then this would help insurance companies a lot. This is however not allowed in the Netherlands, and Kees Keuzenkamp from the ministry of Internal Affairs explained the policy developments in this area (NL and EU), including the planned Dutch eID smartcard (called eNIK, elektronische Nederlandse Identiteits Kaart). Bottom-line (in my wording) is that the decision on eNIK will be taken end of this year (after which it goes to parlement) and that it is very unlikely that DigiD/eNIK can be used as a generic consumer-2-business identity solution. Hein Aanstoot also gave some insight into a new initiative with several large insurance companies to create a breakthrough in a re-usable identity for the insurance sector, I think it is good for these insurance companies that they do not make themselves (too) dependent on the government or others (banks). I also presented, and gave my perspectives on consumer-2-business identities, why this is so difficult (privacy, trust etc), the outcomes of our cidSafe project, my views on DigiD (and eHerkenning) and what the role of government should be (especially: solve it or be very clear you’re not going to do so). I also presented three innovations we are working on that we believe will increasingly become important: user control over their data, mobile-centric identity and context-enhanced authentication/authorization. My presentation is on slideshare (dutch!).


Government eID versus identity trust frameworks, at EIC


I spent most of this week in Munich, at Kuppinger Cole’s European Identity Conference. This had again a full program with presentations and panels on digital identity, GRC and, of course, cloud. Some personal high-lights were presentations and panels on:

  • externalization of authorization (XACML 3.0 won an identity award)
  • privacy (including personal clouds/datastores, Qiy won an identity award)
  • consumer identity/trust frameworks/OpenID (including an interesting presentation by Andrew Nash from Paypal). 
  • and mostly the off-sessions discussions with leading people in the digital identity area

I also had a presentation myself on consumer identity, and participated in panel. I presented my ideas on government issued consumer/citizin identities versus doing this through the market via an identity trust framework.

Quotes from IT-security-in-2010


While catching up on my reading my favorite blogs, I read Bruce Schneier’s blog post on IT security in 2010 (already a couple of weeks old …). Worth the read, especially these quotes:

One old trend: deperimeterization. Two current trends: consumerization and decentralization. Three future trends: deconcentration, decustomerization, and depersonization.

IT security in 2020 will be less about protecting you from traditional bad guys, and more about protecting corporate business models from you.

With decustomerization Bruce refers to the trend that we get IT services for free, but then become the product contrary to the customer, e.g., Google, or Facebook. Eve Maler also has some blog posts on this, for example “The price of free service“.

Internet identity solutions: 3, 3.5 or 4 parties?


When scaling an internet identity solutions (or identity federation or trust frameworks) to many relying parties and identity providers, one is bound to run into scalability issues. I’m not referring to the amount of users, or logins/transactions, but to the relationships that need to be formed between the identity providers and the relying parties. To make things complex, there are technical issues related to this, and organizational issues. I simplify this here to four issues: the technical issues have to do with finding the necessary meta-information (URLs etc), and with protocol translations (not relevant for all scenario’s). The organizational issues have to do with trust (who is part of the federation/trust framework etc) and business aspects. The business aspect is related to business model: in lot’s of business models someone, typically the relying party, is paying another, typically the identity provider. For example, imagine a trust framework in which 100s of relying parties would use 10s of identity providers, and needing a contract between them. This quickly becomes a combinational explosion that does not scale without some form of automation or intermediate party.

Different internet identity solutions address, or do not address, these issues in different ways. In this blog post I write down my current thinking on this subject, hoping for input from others. The alternative architectures I found are:

  1. A single IdP – avoid the issue altogether. This kind of monopolist identity provider is however not an option in many cases.
  2. Centralized meta-information – centralize the meta-information, this obviously addresses the technical issues, and can also help with the trust issue since this list can serve as a whitelist. (This list does not have to be physically centralized, and can also be a list-of-list etc). It does not help with the business aspects, or protocol translations.
  3. Hub – one central component managed by a (very) trusted party that can basically address all four issues mentioned above, but does become a more-or-less monopolist, as used by for example SURFfederatie.
  4. Broker – similar to the hub architecture, but there is more than one hub (allowing competition between them), as used by for example eHerkenning (eRecognition).

The figure below depicts the four alternatives, with examples (biased to the Netherlands). The numbers indicate the amount of connections from the perspective of the source of the arrow.

There are three major arguments that came to my mind while looking into the architectural alternatives (ignoring the single-IdP architecture):

  • Standards compliant – What is interesting is that most (or all?) identity federation standards basically assume the world consists of three type of parties: users, relying parties (aka service providers) and identity providers, and have no concept of meta-data repository, hub (3.5 ? parties) or brokers (4 parties). Going into details is too much for this blog post, but I found that staying standard conformant can clash with the hub and broker architectures, or extensions to the standards are needed that may make it difficult to use COTS federation software (including for the meta-information architecture).
  • “Justifyable Parties” – in accordance with Kim Cameron’s Laws of Identity nr 3, there have to be good reasons to add parties, especially when they are in the protocol flow and have access to privacy sensitive information or/and are a security risk. For hub and broker architectures, this can be a difficult trade-off.
  • Security – related to both arguments above, but end-to-end security can and I think often is broken when introducing a hub or broker. The hub/broker thus needs to be trusted to an extend that for certain scenario’s is not desirable.

A major benefit of a hub or broker model is that should be easier for relying parties to hook up to the federation, both technically (there only need to connect to a single hub or broker), and organizationally (they trust the hub/broker to keep track of who is trusted, they only need to have a single contract contrary to many for each identity provider).

Disclaimer: the above thinking is work-in-progress, and I’m struggling with simplicity vs accuracy …