User consent pilot for SURFnet


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 …


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?


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)


Recently the Dutch company Innopay published, on behalf of the Ministerie of Economic Affairs, a report called A Network Approach to E-identification ( 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 ( .  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.

User-centric SAML?


Let me first introduce user-centric identity (people who know this can skip to the second paragraph). Not so long ago OpenID en InfoCard where introduced as user centric identity standards, contrary to ‘old fashioned’ identity provider centric standard like SAML. Without going into details, user centricity boils down to providing user controlled privacy, i.e., providing informed consent. And I of course do not mean some legal disclaimer that you have to agree to as a user to be able to use some service. The idea to provide actual information on what information would be shared between an identity provider and a relying party, and asking the user for consent before sharing this. InfoCard inherently provides this, and does this with a piece of software on the client. OpenID provides this though a webpage.

We did a project for SURFnet, the Dutch NREN, to study if and if so how we could make their SURFfederatie (identity federation for higher education and research) provide user controlled privacy. The SURFfederation support different protocols, but is mainly SAML WebSSO based. We analyzed different options, focusing on providing user controlled privacy through InfoCards and doing this through SAML. The latter option is less used, but there are precedents, like uApprove (for Shibboleth) and the Consent module for SimpleSAMLphp. Ignoring lots of details, SAML WebSSO works roughly the same as OpenID (by redirecting the browser from relying party to the identity provider, and back), and user controlled privacy can be implemented in a similar fashion for SAML WebSSO as for OpenID.

The choice between InfoCards and what I’ll call user-centric SAML is not a trivial one, both have advantages and disadvantages. And besides, it was not clear if the users (students and employees of universities etc) even want to be bothered with user controlled privacy. We figured that the best way forward researcher user centricity was to simple ask users what they want. We considered doing this through some large-scale survey, but decided that a small-scale but in-depth user study would provide more useful results. My colleague Ruud Janssen, an experienced user researcher, did this user study. Using mockups he asked users if they wanted control, and if so, if they prefer user-centric SAML or InfoCards. Although the number were too small to be statistically significant, there was a surprisingly clear consensus on what the users preferred: user controlled privacy through user-centric SAML. This thus also is what we recommended to SURFnet.

Although I expected that they would like the card-like user interface that InfoCard offers, the user we interviewed did not. We think this is mostly because they were unfamiliar with it, and therefore did not really trust it.

The research outcomes were written down in two reports: the first report discusses the state-of-the-art, design guidelines for user-centric SAML and architectural analysis on using InfoCard vs user-centric SAML. The second report contains the outcomes of the user study. My apologies to non-Dutch speakers: both reports are in Dutch, as requested by our client.

We are continuing the research on user controlled privacy this year, focusing on the user interaction (prototyping, further user studies) and the architectural consequences of user-centric SAML for the SURFfederatie.

The ten benefits of (trusted) consumer identity for a relying party


Over the last few months I’ve been involved in two consumer identity projects (lower-trust with and higher trust for the financial sector, see slide 18). Not surprisingly, it are especially the potential relying parties that need convincing to start relying on identity providers to authenticate and identify their customers. Where I (naively?) used to think that the benefits for relying parties were pretty obvious, I learned that there is more to say on this subject than I realized. This is especially true if we also add the dimension of a trust framework to the discussion. Without going into any details: a trust framework is a set of agreements on top of a technical specification to increase trust. For example, US ICAM for government (C2G) identity, or

In this blog post I list the benefits I most frequently use as benefits for consumer identity for a relying party, and the four additional ones if you use a trust framework. Disclaimer: my ideas on this keep evolving, and since this is a blog post I keep it (too) short.

1. Higher conversion at registration, because there is less hassle.

2. More re-visits of existing customers. Since it becomes easier to login.

3. Loose less customers that forgot their username/password, and give up on your website

4. Less (helpdesk) costs due username/passwords reset. This actually mostly applies to website that offer human assistance, or have an expensive (and thereby typically more secure) password reset. It e.g. does not apply to low-security websites that have a automated password reset using a known email address.

5. Enabler of social web. Identity is a first and in most case necessary step towards to social web. E.g., integrating with social network.

6. Enabler to offer integrated services with business partners. E.g., webshops that offer complementary products.

    The additional benefits for a trust framework (i.e., a more trusted identity), compared to typical self-asserted OpenId-like solutions

      7. More trustworthy and verified attributes. E.g., name or address.

      8. More trusted and privacy-friendly. Hopefully both in the customer perception as in reality.

      9. Scalability in trust levels. Without a trust framework, trust levels quickly becomes a scalability nightmare in case of more than a few identity providers.

      10. Standardized service level agreements. This does depend on the specific trust framework.

      Of course, there are also disadvantages, risks and market entry issues, but I want to be optimistic in this blog post 🙂

      Tuesday Update event on (consumer) identity


      My employer organizes networking events called Tuesday Update by Novay. The theme this time was identity, and more specifically consumer identity (consumer2business). We had an audience that was a very good mix of business people (financial industry, some media, some operators), government, ‘identity industry’ and people who more generally are involved with innovation. It was an interesting and lively event!

      We invited Frank Leyman from FEDICT to give a talk on the Belgian eID, and it’s usage for consumer identity. FEDICT is the Belgian government organization responsible for the eID card. The Belgian government eID can, contrary to the Netherlands, be used by private businesses, and they appear to be ahead of the Netherlands in this area (e.g., an actual eID card …). This made it a very interesting case, and Frank explained the different functionalities very well. See here for his slides.

      We also invited Yme Bosma from Hyves to present the Hyves view on identity. Hyves is the by-far-largest Dutch social network, and Hyves is, as its US/international counterparts, becoming an Identity Provider for low-trust identity. Think OpenID, oAuth etc. Hyves is, with some limitations, also a relying party. What’s especially interesting to me is that Yme is quite straightforward on their business case (my wording): we provide more value to our users, and it’s easy to do, so we do it. See for his slides.

      I also gave a presentation, discussing among other business models, market entry en privacy aspects. And I advocated user centric identity, and our personal buzzword: mobile centric identity. I also briefly discussed our high-trust consumer identity for the Netherlands project proposal, and the initiative (by ECP-EPN) which I’m becoming more involved in (as project manager for the proof-of-concept). See for my slides (the first few slides have some Dutch, but don’t worry, you can easily skip those).

      Presentations on Id Fed, user centric and mobile centric identity


      I gave two presentation recently that I’ll share in this post. They were for quite different audiences, and in different countries, but both in the area of identity federation, user centric identity and mobile centric identity.

      The first presentation was at the Dutch Identity 2009 event, which was co-located with ISSE 2009 this year. This took place in Schevingen (The Hague), on 6-7 October 2009.  I presented my views on trend in identity federation, and user centric identity. Among others, I argued that SAML is just as user centric than OpenID, or at least, can and should be…

      Highlights on Identity/ISSE 2009 for me were the presentations by Don Schmidt (Microsoft), who talked about claim-based identity, and a presentation on the Norwegian BankID, which discussed the status of the Norwegian collaboration between banks to provide identity services to public and private sector.

      The second presentation was at the National eID & ePassport conference, which is taking place as I type this (22-23 October 2009), in Lisbon. It was organized by among others Multicert, who invited me to talk about and discuss mobile centric identity. It was an audience not very familiar with user centric identity, so I first introduced this. I then argued that this implies mobile centric identity, and that using the mobile phone is only the first step towards mobile centric identity.

      No need for Level of Assurance level 1 and thus OpenID for e-government?


      In both EU and US there is a lot happening on how citizens identify themselves for e-government services, especially the STORK project in the EU, and the ICAM work in the states. Their approaches to e-government identity are drastically different, but I’ll focus in this post with what they share: levels of assurance. Basically level of assurance refers to how certain an identity provider is w.r.t. the identity of the user, which depends on both the used authentication means and the identity binding process (see, e.g., here for an informal explanation) . Both sides of the ocean use (more or less) the same four levels that originate from NIST:

      1. Level 1: Little or no confidence in the asserted identity’s validity.
      2. Level 2: Some confidence in the asserted identity’s validity.
      3. Level 3: High confidence in the asserted identity’s validity.
      4. Level 4: Very high confidence in the asserted identity’s validity.

      Looking at the US profiles for OpenID and InfoCard, what got my attention right away is that OpenID is only permitted for level 1 (i.e., no confidence), and that InfoCard is permitted for levels 1 to 3 (I couldn’t find the levels for SAML). This seems to me a good decision, OpenID is much less secure than InfoCard, and (in it’s current version) should IMHO only be used for low security e-services. I had a brief discussion with my colleague Bob Hulsebosch, who was the main author of STORK D2.3 deliverable (Quality Authenticator Scheme) that describes the mapping of the different national authentication levels to the STORK (NIST based) levels. My conclusion from this discussion is that I’m not convinced of the need for an assurance level 1 solution for e-government, and, as a consequence, of the usefullness of OpenID for e-government. Most e-government services I expect are level 2 and up. This is also confirmed by the fact that many EU countries (including the Netherlands) do not have a level 1. Also the examples in the US document “E-Authentication guidance for federal agencies” for level 1 seem somewhat far fetched IMHO. And even if there are some significant e-government services for which level 1 would be ok, then still InfoCard would be much preferred because of it support for higher levels as well.

      Of course, I only follow the US e-government identity discussion from a distance, and maybe there are excellent reasons for supporting a level-1-only scheme.  Anyone who has a pointer to an explanation for this, please send this to me. Also a motivation for the Levels of Assurance decisions for OpenID, InfoCard and SAML is very welcome.

      What I didn’t cover explicitly in this post is the very interesting choice to support all three major identity (federation) standards OpenID, InfoCard and SAML. Most (all?) governments that I’m aware off  use only SAML.

      paper on ePassports and InfoCard



      We’ve been working on ePassports for a while now, using the chips embedded in passports for online authentication. For a couple of years now passports have an embedded chip with information on the passport holder (social security number, name, birth date etc), standardized by the International Civil Aviation Organization. This chip is primarily used to facilitate automated inspection at border control, but can potentially be used for online authentication as well. Without going into technical details here, this means that a ePassport can be considered a state-of-the-art smartcard (contrary to apparantly Canadian driver licences)  that is issued via a trusted process, and which can be used to authenticate for e-government as well as for non-government services.

      Our work basically had two dimensions:

      1. Figure out what the consequences of using ePassports for online authentication were – this boils down to the privacy sensitive information on the holder that is stored in the chip. Details vary per country, but since the ePassport was not designed with online usage in mind, you basically have to share all the data, which includes things like social security numbers. This is a major concern, which basically means you have to have a very-trusted-third-party to filter out attributes (minimal disclosure).
      2. How to use this in combination with Information Cards – We did an experiment where a InfoCard-based identity provider would use the ePassport to authenticate the user, as well as pass the government-certified attributes to relying parties. Of course: with user consent!  The good news is it works, the bad is that IMHO it’s a bit complicated to explain to the average user, especially to create the InfoCard.

      Last week my colleague Dirk-Jan van Dijk (who did most of the development) presented a paper on the SecureComm conference on our ePassport & Infocard work. Since SecureComm has post-proceedings, I cannot link to the final version of the paper just yet, but just send me an email to get a final-except-maybe-layout-stuff version.

      The lead for this work is with my colleague and ePassport guru Martijn Oostdijk. Martijn will give a presentation on our work on at RSA Conference Europe 2009 (next month). Martijn also made a nice overview of articles in the Dutch press on our work, including an English translation of an article in the business newspaper Financieel Dagblad. This work was partly sponsored by the NLnet Foundation, the software is open source.

      UPDATE on 26 october 2009:  The paper can now be downloaded from, or from my homepage at the University of Twente.