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 🙂