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 …

Two things happened today that made me think about how current measures against identity theft are so very naive. The first is a US bank that I’m a customer with. I hardly ever log in on their website, and of course had forgotten the password. To assure that I am myself, I had to provide two answers about myself that I’m sure many (10s or 100s of) people know, and many more can very easily find out (including place of birth, which I had to put on page 5 of my PhD thesis that is publicly downloadable). And since the web interface did not allow me to do what I wanted (to terminate the account), I had to call them. During this call I had to provide those two same answers, plus my home address (which is listed in the phonebook). The funny thing is that I had to provide these answers twice during the same phone call, which did not make me feel more secure at all …

This type of static knowledge authentication is simply NOT suitable to authenticate any transaction that requires more than a very minimal level of assurance, and it is very naïve to use it for online banking (see also).

The second thing that happened today is a commercial I saw from the Dutch government, part of a campaign for a safer internet (“Veilig Internet. Heb je zelf in de hand”). The campaign seems to focus on peoples own responsibility to prevent identity theft.  The commercial however was very limited, stating that people should change their password once in a while, and make sure who you email your personal data. The first recommendation is very naïve because 1) I’m convinced people don’t do this unless forced to and 2) it doesn’t help much against e.g. malware, phishing or using the same password at many sites. The second recommendation assumes that personal data is used to authenticate yourself, which it simply shouldn’t (see the first paragraph).

Although I welcome the attention that this campaign brings to the issue of identity theft, I wonder if spending more energy and time on better authentication and identity solutions for the internet wouldn’t be more effective than this campaign.

• 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 (http://www.innopay.com/index.php/plain/newsletters/04_2010_e_identity_as_a_two_sided_market_the_business_case_will_drive_adoption_not_the_technology) .  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.

From 2004 till 2009 my biggest project was the Freeband AWARENESS project, a collaborative research project in which we worked on context-aware middleware for mobile applications, focusing on mobile health applications. In 2008 a journalist interviewed me for an article on telemedicine, to appear in a Microsoft internal magazine. I never got to read this article myself, but earlier this month, and two years after the interview …., it also appeared on a Dutch online magazine. For those interested, and able to read Dutch: Telemedicine: the 24-uurs virtuele thuisdokter.

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.

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

Together with my colleague Martijn Oostdijk (see also his post) we did a project on Mobile PKI technology. We did a technology assessment, focusing on security and also usability, and consulted our client SURFNet on its application for higher education and research.

It proved to be a very interesting project, not only because of the interesting and promising technology, but also because we are advocating what we call mobile centric identity, and Mobile PKI is a good example of “use your mobile phone as an authentication device”. We concluded that Mobile PKI is both a secure and usable technology, and that the main issue is the business model (since the SIM is owned by the mobile operator).

The report that came out of the project is publicly available: in Dutch and in English. Among others, SURFnet employees Roland Rijswijk and Joost van Dijk also provided input and feedback on this report. Below I’ve copied the management summary.

A GSM/UMTS telephone has a SIM card. This is a standardised smartcard that is issued to the user by the telecom operator and is primarily used to authenticate the user on the mobile network. However, the SIM card has more potential uses. For instance, it allows for secure storage of digital keys that can be used for online authentication and digital signatures. This is referred to as Wireless PKI and Mobile PKI.
This report is an assessment of Mobile PKI technology and its potential application for authentication in education. This assessment focuses on its security and its application within the educational domain, with a specific emphasis on applications for SURFfederatie.
Mobile PKI employs encrypted SMS text messages that are used to represent authentication or a digital signature. The user has to express consent by entering a PIN code that secures the private key and which typically needs to be entered for each transaction separately. The relevant standards for this are well established and are supported on all mobile phones. This has advantages compared to other secure means of authentication. For instance, no additional authentication device is required, which also means that no software needs to be installed by the user on either the phone or on other client devices such as a PC. Neither is there a need to manually enter codes, as in the case of one-time passwords via SMS text messages. This improves user-friendliness. Malware such as viruses and key loggers that may have been installed on a PC cannot interfere with Mobile PKI.
This report considers the issue whether Mobile PKI is a secure means of authentication. The analysis identifies a “man in the middle” channel. However, the authors of this report deem Mobile PKI to be more than sufficiently secure compared to other means of authentication and considering the kind of applications in (higher) education.
In our view the most important issues regarding Mobile PKI technology are not related to security or technology but have to do with the costs and the business model. In the Netherlands, Mobile PKI technology has only been deployed for limited pilots and it is therefore difficult to estimate the costs. These could turn out to be too high for many applications in the educational domain if there are no other large-scale deployments of Mobile PKI. A related aspect is the business model. Use of this technology requires the cooperation of the mobile operator, who is the owner of the SIM card. This means that the cooperation of all mobile operators is required for a large-scale deployment.
The final conclusion of this report is that Mobile PKI provides a secure means of authentication that in time will find wide application within the educational domain in the Netherlands. For the near future Mobile PKI will only be employed for services that require a high standard of security and that are used by a limited group of employees due to a) the expected costs, b) insufficient insight into the business model, and c) limited support from the mobile operators. It seems too early for a deployment for students or for general authentication for SURFfederatie or any other large-scale application for SURFnet, Kennisnet or other service. In the meantime it may be useful to consider one-time passwords via SMS text messages as step-up authentication or for password reset because this is cheaper and prepares users for Mobile PKI.

Doing this in OpenID (AX actually) is a bit beyond the current spec, but not so difficult (see also this draft from Google/Yahoo). What is more difficult is the semantics of what “verified” means for a specific attribute. We are considering simply defining one of more verification processes per attribute. An example of a process for a verified bank account attribute is: the bank account was verified by requiring the user to transfer some money to the IdP. By lack of a standard that describes these verification processes, we’re inventing them ourselves using common sense combined with existing practises at the involved IdPs. This is work in progress, so I cannot give any firm statements yet on how well this will work, and if this will also scale. I’m happy if it will work for a small set of frequently asked attributed, and for most verification processes. Alternative approaches include

1. Defining numeric levels per attribute, comparable to the 1 to 4 of the NIST levels of assurance with higher meaning better, and mapping the verification process used by an IdP to one of these levels.
2. Defining it simply as “verified” (boolean), but defining the minimum amount of verification an IdP should have done for that specific attribute. This can be considered the same as alternative 1, but only with 2 levels (verified or not verified).
3. Defining it simply as “verified” (boolean), without semantics, and thus leaving it up to the RP to check with the IdP what this means for that specific attribute from that specific IdP. We can of course provide a URL to an explanation from the IdP on how the attribute was verified.

A recent blog post of Eve Maler describes her ideas on levels of assurance. She makes a good case that the 4 levels from NIST are not suitable for use cases were a website want to recognize a returning user, without needing to know who that user is exactly (persistent pseudonym). Or put differently: have a good authentication, but no identity binding process. She also pointed to this interesting diagram from an Internet 2 Tao of attributes workshop that I would have loved to attend.

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).