Liberty, LECPs and user-centric identity
Yesterday I attended a
Liberty Alliance Project webinar on user-centric identity (see here for some
press coverage and, no, although I asked the question about user experience referred to in the piece, I am definitely NOT a developer working with Microsoft's InfoCard).
Some of you reading this are perhaps thinking "Must have been a short webinar - isn't Liberty an enterprise-centric play". Until about 3 weeks ago, I would have agreed with you, as I discuss in our
report on identity management:
Current models for identity federation fall in to one of three types:
bi-partisan, involving federation of identities between two service providers
hub-and-spoke, involving federation between a dominant service provider and a number of its partners
a “circle of trust” involving federation between multiple service providers operating as peers.
These solutions are typically based on dedicated technologies and/or products implemented in a point-to-point fashion with the federation, rather than the individual, at the centre. As a result, it is highly likely that the individual will have to possess a different digital identity for each federation they become involved in and furthermore will be subjected to multiple, potentially inconsistent, experiences.
Identity management technologies and standards need to move to support a federated design, which is network-based (a “super” circle of trust) where today’s federated identity solutions are themselves federated
I began to change my mind, however, when I read Liberty's
Personal Identity white paper, published at the end of March. At the time I felt, and this was confirmed by
John Kemp of Nokia during the webinar, that it had dawned on Liberty that user-centric identity had become a hot issue, not least because of the work of Microsoft's
Kim Cameron with the
identity metasystem and
InfoCard and the recent buzz of interest around the
Higgins project).
In a nutshell, the Liberty paper explains how identity selector capabilities, which allow an individual to control how their identity data is passed between identity providers and service providers, can be implemented using the Liberty specifications. These capabilities depend on part of the Liberty ID-FF web-based, federated single sign-on specifications, known as the Liberty-Enabled Client or Proxy Profile (LECP).
Without LECP, when an individual makes a request to access a service which requires authentication by a different identity provider, their browser is automatically redirected from the service provider's site to the identity provider without user intervention i.e. the user is not in control.
LECP acts as intermediary, allowing the user to control which identity provider is accessed. In addition, LECP can be used to implement identity services, based on Liberty's ID-WSF web services-based specifications (authentication, discovery, personal profile), as user agents running locally e.g. in a web browser on a mobile device. The webinar included some live demonstrations of the LECP in action, which you can get some idea of from Hubert Le Van Gong's (the other webinar presenter)
blog. This is definitely a move in the right direction by Liberty and holds out some hope for my "super" circle of trust. However, there are some important issues still to be addressed (to be continued ...)
