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.


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

2010/02/04

Over the last few months I’ve been involved in two consumer identity projects (lower-trust with OpenID.nl+ 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 OpenID.nl+.

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

      2009/12/04

      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 http://docs.google.com/a/yme.nl/present/view?id=dg22g52h_10c29qhvdj 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 OpenID.nl+ initiative (by ECP-EPN) which I’m becoming more involved in (as project manager for the proof-of-concept). See http://www.slideshare.net/wegdam/consumer-identity-tuesday-update-on-1-december-2009 for my slides (the first few slides have some Dutch, but don’t worry, you can easily skip those).


      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.