Do’s and don’t’s for DigiD

2011/12/20

Nieuwe logo DigiD

DigiD is the Dutch national digital identity solution for citizin-2-government. Although not the most secure solution around, it is one of the more succesful ones with respect to actual usage. DigiD is actually not only for e-government services, but also for online services in healthcare and pensions (since they can use the Dutch social security number). For such a ‘lucky’ company, which is going to use DigiD next to an own identity solution for consumers, we did a series of interviews to determine the do’s and don’t’s of implementing DigiD. My colleague Wouter Bokhove was in the lead for this, and published a blog post summarizing some of the main finding. It is in Dutch, and be be found here or for your convenience copied below. Amongst others we advised on using the new SAMLv2 interfaces or the ‘old’ A-Select interfaces, and on how to use te Levels of Assurances concept.

 

DigiD: een goede voorbereiding is het halve werk!

Stel: je hebt als organisatie in de pensioen- of zorgsector een Mijn-omgeving waar je online zaken kunt regelen. Een deel van je gebruikers heeft een account tot deze Mijn-omgeving op basis van een gebruikersnaam en wachtwoord (met alle nadelen en beperkingen van dien), maar je bent op zoek naar een goedkoper, veiliger en/of gebruikersvriendelijker alternatief.

Is DigiD dan het antwoord? Wanneer is het nuttig om DigiD te implemeteren? Waarom zou ik nog een eigen gebruikersnaam/wachtwoord-combinatie aanbieden? Wat is belangrijk bij het implementeren van een DigiD koppeling? DigiD heeft verschillende koppelvlakken, welke moet ik kiezen? Wat gaat er met DigiD 4.0 veranderen, welke ontwikkelingen zijn nog meer relevant en welke impact zullen deze veranderingen en ontwikkelingen kunnen hebben op de keuzes die ik nu maak? Hoe zorg ik voor een toekomstvaste identiteitsarchitectuur die hiermee om kan gaan?

Novay heeft voor een grote Nederlandse financiële dienstverlener een aantal adviezen geformuleerd die op deze vragen een antwoord geven. Hiervoor is niet alleen gekeken naar de huidige situatie van deze klant en de publiek beschikbare informatie over DigiD, maar is ook uitgebreid gesproken met ervaringsdeskundigen uit de zorgsector, system integrators en met Logius. In deze blogpost schrijf ik kort een paar van de aanbevelingen die interessant zijn voor een breder publiek:

  • Er kunnen verschillende redenen zijn om gebruik te willen maken van DigiD:
    • het wordt mogelijk om diensten aan te bieden waarvoor een hoger zekerheidsniveau nodig is (t.o.v. een eigen gebruikersnaam en wachtwoord);
    • het gebruik van DigiD verlaagt de drempel voor klanten om gebruik te maken van de Mijn-omgeving; hierdoor zullen meer klanten gebruiken van dit (typisch goedkopere) kanaal;
    • er zal minder gebruik gemaakt worden van het eigen authenticatiemiddel, waardoor nieuwe identiteiten uitgegeven hoeven te worden en er minder belasting zal zijn voor de helpdesk (bv. voor het resetten van vergeten wachtwoorden);
    • het is eventueel niet langer noodzakelijk om een eigen authenticatiemiddel aan te bieden (dit is o.a. afhankelijk van het feit of alle klanten wel een DigiD kunnen aanvragen).
  • Er moet gekozen worden tussen koppelen met het ‘oude’ A-Select koppelvlak of met het ‘nieuwe’ SAML v2 koppelvlak. Het gebruik van SAML v2 is aan te bevelen omdat dit meer toekomstvast is (SAML v2 is een OASIS standaard). SAML v2 wordt vanaf DigiD 4.0 ondersteund (SAML v2 is nu ook al beschikbaar bij DigiD Eenmalig Inloggen). De release hiervan is echter uitgesteld van 1 oktober 2011 tot na 1 april 2012.
  • Ondanks het feit dat het gebruik van DigiD en de begeleiding bij de implementatie van DigiD door Logius momenteel nog gratis is, is het verstandig om rekening te houden met het feit dat dit op termijn anders zal worden. Het is op dit moment niet te voorspellen hoe duur dit zal zijn, en of dit zal verschillen per zekerheidsniveau.
  • Doe een risico-inventarisatie van de huidige en geplande diensten voor de Mijn-omgeving en bepaal welke zekerheidsniveaus hiervoor nodig zijn. In verband met de toekomstvastheid is het verstandig hierbij gebruik te maken van de zekerheidsniveaus zoals deze gedefinieerd zijn in het Europese STORK project (D2.3, geschreven door Novay in opdracht van het ministerie van BZK).
  • Logius is zeer streng met betrekking tot de communicatie-eisen en het blijkt dat Logius freuent (pre-)productie-omgevingen afkeurt als deze niet voldoen aan deze eisen. Dit betekent dat een aansluitende partij zich geen enkele vrijheid kan veroorloven ten aanzien van de voorgeschreven teksten en het gebruik van het DigiD logo.

Bovenstaande adviezen zijn opgesteld in de periode voor ‘Lektober‘. Naar aanleiding van de DigiD-gerelateerde recente veiligheidsproblemen bij o.a. gemeentes die hieruit naar voren zijn gekomen, kan er nog een advies worden toegevoegd:

 


No more Cardspace …

2011/02/16

Microsoft announced yesterday that Cardspace 2.0 will not be shipping. Or to put this  more directly: that they’ve stopped with Cardspace. This is not a big surprise, uptake was very slow and Microsoft already showed signs of less-than-fully supporting Cardspace/InfoCards for a while now.

Cardspace was IMHO a promising approach to some of the privacy, security and usability concerns for federated identity systems, but it lacked adoption. Part of the reason as Mike Jones puts it is it is not drop-dead simple to use. Lack of user acceptance is  also confirmed by the user study we did for SURFnet in 2009, where users basically distrusted Cardspace. Other reasons I think are lack of an easy migration path from existing standards, and slower-than-hoped  update of identity federation in the consumer space in general.

Anyway, Microsoft stopping Cardspace will probably mean the end of the used InfoCard standard as well. This makes things clearer in the standards department, which a consolidation on basically OpenID (/OAuth) and SAML. And especially Facebook with a non-standard protocol to do similar things.  Not that standards are the most important, I agree with Eve Maler (now Forrester) when she states:

when it comes to lightweight consumer-scale federated identity, the specific protocol matters less for success than the user base, the nature of the data available about those users, and the tooling available for relying-party integration.

Even though the protocol may not  be the biggest issue for a federated consumer identity solution, it is still not a trivial one. Especially the issue to have a web-based client (i.e. OpenID or SAML WebSSO) or an active client (Cardspace/InfoCard) is one that remains interesting because of the consequences for usability and security.


Most popular ‘social logins’

2010/12/15

Janrain produced some nice statistics on usage of OpenID and similar technologies to use credentials from, again typically, social networks to log in on other sites. They use ‘social login’ as a term, which sounds probably better than OpenID or identity federation 🙂 There is a statistic specifically for Europe, based on logs from 20 of their European customers. By the way, they don’t have US statistics on their blog post, maybe they just assume the international statistics are the same as US ones, or maybe they simply don’t have that many non-US customers.

Below the part of the blog post on Europe. Among others, it claims that Hyves is growing as an identity provider.

Similar to last quarter, we want to note that Windows Live remains twice as popular a social login provider in Europe as in the US, and its share has increased from 8% to 11% despite the emergence of more localized social networks and email providers.  These providers, such as Hyves (Netherlands), Netlog (Belgium), Web.de and GMX (Germany) comprise over 10% of social logins from our sample of 20 European customers.  Their growth in social login popularity across the Atlantic comes at the expense of Google, Twitter and Yahoo!

European Social Sign-On Preferences

Most popular overall is Google (38%). Top five combined has 92%, but I expect for specific domains (e.g., business-2-business where LinkedIn would be popular) or region (e.g., Netherlands with Hyves) this top five would have other names in it.


User consent pilot for SURFnet

2010/10/08

Together with my colleagues Ruud Janssen and Dirk-Jan van Dijk we have been working for SURFnet to help them if, and if so how, they should add a user consent feature to their SURFfederatie identity federation service. See also this previous post on user-centric SAML that describes what we did last year. We continued this year, doing additional user studies, deciding on architectural issues, developing a prototype and doing a pilot. This pilot started two weeks ago J, see also a SURFnet news item (Dutch) on this. The pilot is with three of the bigger Dutch universities, and students/employees that go to the selected service providers will be asked to participate in the pilot. They go through the consent pages, and we bother them with two online surveys to get their feedback. It’s too early to predict the outcome, but the pilot itself seems be going well.

At ISSE 2010 I gave a presentation on the current status of this work, the presentation is on slideshare. In December we’ll finalize a report with the outcome of the pilot, after which it’s up to SURFnet to decide if they’ll add this feature to the SURFfederatie.


Digital Medication Dossier, as offered by my pharmacy …

2010/09/22

Digital Medication Dossier

I recently stumbled on a possibility offered by my pharmacy to get online access to my medication dossier (access to previously prescribed medication, functionality for repeat prescriptions). My pharmacy is part of a larger franchise chain in the Netherlands, and this Digital Medication Dossier is offered for all member pharmacies. In itself I think offering this online access is a good idea, I want to have easy access to information about medical information about me, including my medication… Also because national initiatives are going quite slow, I appreciate innovation by individual healthcare providers.  So I went to try it out. Of course, I was especially focused on how they handled the identity/authentication/privacy aspects.

At a high level they seem to have things under control. They use two-factor authentication (username/password and SMS one-time-password), combined with a face-2-face check where I had to show my passport (or ID card or drivers license). This is roughly the same as is proposed for patient access to their the national health record (at least, till eavesdropping of SMSes becomes too easy).

There are however three major concerns that I want to discuss.

Re-use of identities. I have to create a separate identity just for this service. I will of course forget my password, have to remember to register a new phone number should this change, have to go there to show my passport etc. I want to re-use a previously established identity! As far as I can see there is no reason why they couldn’t use the Dutch national citizen-to-government identity solution DigiD level 2, possibly supplemented with a face-2-face check by themselves (this is lacking in current DigiD level 2, but is expected to be added for access to the national health record).

Sidenote: earlier this year NICTIZ asked me to write a whitepaper on how to deal with online identity for consumers/patients. It is available on their website (in Dutch, titled “e-identity: zorgeloze identificatie van zorgconsumenten”). I advocated the re-use of existing identities, including usage of DigiD (at an appropriate level of assurance). It is targeted at non-identity experts, such as policy makers in healthcare and people working for health providers that want to deploy e-health services. Related to this, an article in the Dutch ICT Zorg magazine has some interesting quotes on using DigiD for health services.

Reset of password by email: Another point is that when someone forgets their password, a new password is sent by email. This password is thus send unencrypted (and it is only 4 chars). Not a good idea I think. What I considered is worse than it being unencrypted is the risk this poses for people that lose their smartphone. If someone else has access to your smartphone, it typically means that the thief/finder has access to not only SMS messages but also email since smart phones are typically set up to receive emails without requiring the user to provide a password. With increasing penetration of smartphones (about 1 out 5 persons in NL and increasing) this is significant. Or put differently: I do NOT consider access to email and SMS as separate factors anymore.

HTTPS inside a frame: the privacy and security sensitive information is I think sent over a HTTPS connection. I checked this for one of the pages where this is the case, and suppose they did they for all other pages as well. This is however basically hidden from the user since the service runs inside an iFrame that is in a webpage that uses HTTP. The address bar therefore does not say “https”, and there is no “padlock” next to the address bar to click on to check the certificate. It is therefore not transparent for users if HTTPS is used, nor can they verify with who the secure connection is set up. Even if lots of users won’t be aware, empowering users to check these things is the least we can do. In addition, the webpage displays a padlock-icon inside the page that when you hoover over it, that will say that SSL is used. This is training users the opposite of what we should train them. Phishers and other cybercriminals will be grateful.

My guess is that my pharmacy does it like this because the Digital Medication Dossier is actually offered through another company (Pharmeon), and offered it inside a frame is an easy way to integrate the Digital Medication Dossier in the website of the pharmacy. This is however not nearly a justification IMHO.

Especially my first two concerns could be addressed if they simply used a high-trust government (DigiD level 2+) or non-government federative identity solution. High-security non-government identity solutions for consumers are not yet available in the Netherlands, but we’re working on this in the cidSafe project.

UPDATE: update deeplink url to Nictiz whitepaper on 12 January 2011

UPDATE: and again on 26 May 2011


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.