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

2011/10/05

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

2011/05/13

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.


Internet identity solutions: 3, 3.5 or 4 parties?

2010/07/19

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 …


Network Approach to E-identification (eRecognition)

2010/04/20

Recently the Dutch company Innopay published, on behalf of the Ministerie of Economic Affairs, a report called A Network Approach to E-identification (http://www.innopay.com/index.php/plain/newsletters/04_2010_e_identity_as_a_two_sided_market_the_business_case_will_drive_adoption_not_the_technology). This is an interesting report that gives some background and motivation for the Dutch eRecognition program which works on a trust framework, of scheme, for business-2-government identity. Together with Paul Oude Luttighuis, a colleague and interoperability expert, we wrote a short reaction. This reaction is below, but in Dutch … For non-Dutch speakers, among others we discuss:

  • We support the choice for a network model (or trust framework or scheme)
  • The report advocates the use of a four party model, as is used in the financial world, contrary to the probably more common three-party model (user, identity provider, relying party).
  • We discuss the risk that new parties trying to enter this market are prevented from doing so by the parties already active in it.
  • We discuss the opportunity to have mutual authentication, i.e., the service provider could also authenticate to the user.
  • We discuss semantic issues, and pseudonyms.

What follows is the Dutch text (feel free to experiment with Google Translate …).

Wie bent u om mijn klant te zijn?

Recent publiceerde het bedrijf Innopay op verzoek van het Ministerie van Economische Zaken hun rapport A Network Approach to E-identification (http://www.innopay.com/index.php/plain/newsletters/04_2010_e_identity_as_a_two_sided_market_the_business_case_will_drive_adoption_not_the_technology) .  Dit belangwekkende rapport bespreekt het gedachte­goed ach­ter hui­dige e-identity-ontwikkelingen bij de Nederlandse overheid. Paul Oude Luttighuis ( Enterprise Interopera­bility expert bij Novay) en Maarten Wegdam (Identity Management expert bij Novay) rea­geren.

============================

Het stuk bepleit een netwerkbenadering. Die gaat uit van interoperabiliteit tussen concurrenten, gevat in een expliciete en goed beheerde set van afspra­ken (door het stuk een scheme genoemd), in plaats van een centrale voor­ziening. Als concept is dat niet nieuw, maar in het e-over­heids­veld is inderdaad de “centrale voorziening” vaak het leidende concept. Door in het netwerk rollen te onderscheiden wordt er niet alleen gekoppeld, maar ook ont­koppeld: de rollen krijgen de kans zich in hun eigen dyna­miek te ontwik­kelen. Zo’n model kan daarom soepeler groeien dan een centrale-voorzie­ning-model, zolang de rollen goed gekozen zijn en er voorzieningen zijn om te inno­veren op de koppelvlakken tus­sen de rollen.

Specifiek kiest het stuk voor een zogenoemd vier-partijenmodel, waarin twee hoofdrollen, in dit ge­val de eind­gebruiker en de dienstverlener, elk worden be­diend door een ondersteunende rol aan hun zijde. In dit geval is dat de authentica­tieprovider, die de eindgebruiker voorziet van authenticatie­middelen, en de zoge­naamde rou­ting service, die de dienstverleners toegang biedt tot het netwerk. De kernafspraak in dit netwerk is dan dat alle authenticatieproviders ver­bon­den zijn met alle routing services. Deze we­derzijds gedwongen winkelnering vraagt wel om maatregelen tegen het oneigen­lijk weren van nieuwe toetreders tot het netwerk.

Een ander voordeel van het vier-partijenmodel is dat eindgebruiker en dienstverlener via één partij toe­gang krijgen tot het hele netwerk. Natuurlijk moeten zij dan wel het hele net­werk ver­trouwen en, in­direct, de au­thenticatieproviders en routing services daarbinnen. Overigens is ook een decentraal drie-partijenmodel denk­baar. Sterker nog, gang­bare identity-fede­ratiestandaarden gaan daarvan uit en niet van een vier-partijenmodel. Sommige identity-federaties, zoals de SURFfedera­tie, hebben wel een vierde rol, maar centraliseren deze.

Overigens, het geschetste vier-partijenmodel is asymmetrisch. Bij authenticatie is sprake van twee hoofdrol­len: de partij wiens identiteit wordt vast­gesteld en de par­tij die die vaststelling ontvangt. In het stuk worden de­ze rollen geïdentificeerd met respec­tievelijk de eind­ge­bruiker en de dienstverle­ner. Dat ziet over het hoofd dat in een transactie ook de eindgebruiker behoefte kan hebben aan zekerheid over de identiteit van de dienstverlener. Is het netwerk niet ook daarvoor te gebruiken?

Een andere adder onder het gras is dat het besproken netwerkmodel weliswaar functioneel decen­traal is, maar semantisch wel degelijk cen­traal. Elke eindgebrui­ker die het netwerk als zodanig kent, heeft namelijk maar één identiteit in dat netwerk. Anders kunnen niet alle authenticatie­midde­len worden geaccep­teerd door alle dienstverleners. Dat brengt privacy-issues met zich mee, die niet door het stuk worden bespro­ken. De voor de hand liggende manier om hier­mee om te gaan is om één per­soon meerdere “eindgebruikers” te kun­nen laten spelen, door middel van pseudo­niemen. Dit is gebrui­ke­lijk in modern denken over elektroni­sche identiteit. Het stuk maakt echter niet duidelijk of het afsprakenstelsel dit gaat toe­staan en hoe wordt geborgd dat pseudoniemen niet toch worden ge­combineerd in een omvattender persoonsidentiteit.

Daarnaast heeft een eventuele centralisatie van het identiteitsbegrip ook informatiekundige gevolgen. In rela­tie met een school is een persoon leerling of student, in relatie met een vereni­ging is hij lid, in zijn relatie met een bank is hij bankklant. Dat kunnen écht andere rela­ties zijn, die dus een andere iden­titeit vragen. Denk bijvoor­beeld aan een gezinslidmaat­schap van een vereniging, of aan één persoon die ver­schil­lende relaties heeft met één dienstver­le­ner, in verschillende hoedanig­heden.

Deze semantische kwestie wordt alleen maar groter als dit afsprakenstelsel wordt uitgebreid richting eindge­bruikers die namens hun organisatie optreden, zoals het stuk aan het eind suggereert. Zo zou ook een organisa­tie-an-sich kunnen worden geauthen­ticeerd. Echter, of zo’n optreden wer­kelijk námens een organisatie is, kan van veel dingen afhangen: van een expliciete autorisatie, van de precieze ge­bruikte dienst, van het tijdstip, van de locatie of van de situatie (denk bijvoorbeeld aan noodgevallen). Deze semantische variëteit dreigt veel complexiteit in het netwerk brengen. Het zal in elk geval niet de bedoeling zijn deze genuanceerde autorisatie onmogelijk te maken, nemen we aan.

Tot slot, het stuk claimt dat zo een centralistische machtspositie wordt voorkomen. Moch­ten deze net­werken echter suc­cesvol blij­ken, zullen zij vanzelf een oligopolie of monopolie vestigen en de keuzevrijheid toch weer be­perken. Daarom moet het beheer van het afsprakenstelsel zorgvuldig en voldoende open worden vormgege­ven.