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.


User-centric SAML?

2010/03/11

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.


Mobile User Centric Identity through Information Cards

2009/10/16

infocard-mobile-mockupThere are three things I believe will continue to gain importance in the coming years: identity federation, user centric identity and mobile applications. I can combine them in what we refer to as mobile centric identity. When considering mobile centric identity, we do not only refer to an identity solution that works for mobile applications, but also consider the mobile phone to be a good (or best) way to control your identity when using ‘old fashioned’ PC-like applications (including web browsers). I’ll focus in this post on a specific way to implement mobile centric identity: using InfoCards on a mobile phone. I’ll leave the more general mobile centric identity subject, including how to use mobile phones for authentication (Mobile PKI etc), for another time.

With all its promise, InfoCard has so far been mostly a desktop-only way to implement user centric identity. I looked around for a student to work with me on the subject of making InfoCards mobile, and found Florian van Keulen. He also found the subject interesting, and did his BSc Telematics graduation assignment with me (and Marten van Sinderen). He dived into the status of the different implementations, and analyzed what the issues are to make InfoCard mobile. The good news is that we did not find any reason why InfoCard could not become mobile, and that there are even some first implementations coming. The main issue when porting the InfoCard identity selector appears to be that then needed libraries are not there, making it a lot of work. Making InfoCard mobile is however more than porting the identity selector, the more challenging part is how to (securely) roam once’s identities between the different fixed and mobile devices. This means that a user can use the same identities on his or her mobile phone, as on other (fixed or mobile) devices the user may be using. Of course without having to manually import/export InfoCards… The main contribution of Florian’s work is comparing the different architectures to do this. One way to do this is to store the cards ‘in the cloud’, as Azigo seems to be doing (but they do not have a mobile identity selector as far as I’m aware). The architecture we decided to detail is however a different one: we put the InfoCards and the identity selector in the mobile phone’s SIM card, and connect this via BlueTooth to a fixed PC. It’s more complicated to implement, but we believe it is also more secure. I’ve put Florian’s thesis online so you can read it for yourself: http://www.novay.nl/okb/publicaties/mobile-user-centric-identity-through-information-cards/7248  (titled: “Mobile User Centric Identity through Information Cards, Architectures to use same identities on mobile phones and computers”). Unfortunately, implementing it was too much work for a BSc assignment, but I may find another student or some project to continue working on making InfoCards mobile.


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

2009/10/01

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

2009/09/26
passport

passport

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 http://dx.doi.org/10.1007/978-3-642-05284-2_17, or from my homepage at the University of Twente.