FIDO and its place in the eID ecosystem

2015/01/29

FIDO-BYOAuthn-BYOId

FIDO stands for Fast Identity Online. FIDO is a new authentication specification that makes it easier to integrate with and re-use non-password authentication means: what-you-have and what-you-are. The specification was published in a v1.0 version last December by the FIDO Alliance, which unites an impressive list of large companies (e.g., Microsoft, Google, Samsung) and smaller authentication companies (e.g., Authasas, Yubico, Nok Nok Labs) to “define an open, scalable, interoperable set of mechanisms that supplant reliance on passwords to securely authenticate users of online services”.

Last Friday (23 January 2015) PIMN organized a seminar on FIDO,  which was fully booked with a waiting list even. In this blogpost I’ll summarize what I learned and what I presented on “FIDO and its place in the identity ecosystem”.

Read the rest of this entry »


PayPal and Dutch banks as identity provider

2014/04/10

loginwithpaypalbutton

Today I received an email from PayPal to inform me on updates they are making in their legal terms related to “Log in with PayPal”. That PayPal wants to be an identity provider is nothing new, but this update was a good reason to blog about opportunities for Dutch banks to introduce innovative services in the area of digital identity. See below the cross-post in Dutch from the InnoValor website on this subject.

PayPal en banken als inlogmethode

Paypal heeft vandaag aanpassingen aan de gebruikersovereenkomst bekend gemaakt. Opvallendste voor mij was de toevoeging van “PayPal als inlogmethode”, oftewel, PayPal als identity provider. PayPal is overigens al langere tijd zich aan het positioneren als identity provider. ”PayPal als inloginmethode” is erg vergelijkbaar met hoe Facebook Connect of andere social logins werken, je logt in bij een wesite van een derde partij door op een button te klikken die je browser redirect naar bijvoorbeeld Facebook waar je inlogt met de gebruikersnaam/wachtwoord die je gebruikt voor Facebook. Qua user experience en werking niet heel veel anders dan DigiD overigens. Geen nieuwe wachtwoorden voor elke site, minder gedoe met registreren etc. Voor de techies: PayPal gebruikt OpenID Connect hiervoor, DigiD gebruikt SAML.

Read the rest of this entry »


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.


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.