user-centric identity


I’ve been waiting for the first OpenID provider to offer a certificate based, no password ever, service. Not an SSL service, a certficate authentication based service. That is, a service that simply puts a certificate in your database and uses that to authenticate you. Browsers are well versed in the art of the certificate these days, they have had a while to eek out the rough spots. Auto-installation of certificates from a web page is possible and that allows a pretty seemless experience for sign up and “log in.” Prooveme.com very nearly, almost, but not quite gets it right. When I signed up and briefly tested the service I noted three rather serious problems:

  1. I had to click through a certificate security alert dialog because they used a self signed certificate for the page that installs the user certificate. It is just fine to use self signed certificates for user identification in this case, in fact it is the perfect use case, but I should know who is giving me the certificate and I shouldn’t be trained any further in bad browsing habits. Their users are surely worth a $20 certificate.
  2. Upon signing up for a site I discover that I am not asked if I have authorized the site to identify me. If I log in to a site for the first time I want to be alerted to that fact. There needs to be some level of control here so that I can decide to be auto-logged in to a particular site.
  3. After recovering from the shock of being logged in straight away, I noticed my name had been given up too! That is, er, not cool.

I’m a forgiving sort though, so I shall take comfort in the knowledge that this is a relatively new service and it is still working on these things. Clearing up these issues will get us all a whole lot closer to the ideal provider set up, and I think, the minimum required security for the use of OpenID by anyone who cares about their identity.

Recently Kim Cameron has been defending CardSpace against various assertions that it won’t work offline. As I pointed out some while back, that is pure nonesense. I’ll let you read Kims blog for the details of how such a system might work with CardSpace, but I’ll just say it has to do with delegation. And that’s just a big word for access control, in this case user centric decentralized access control.

There really is no big secret to how this stuff is possible - at some point in time an offline user will be online, and during that time instead of ceding their credentials to the service in the sky (or worse, it happens without choice), they spend the time granting access specific to the service that needs access. That’ll be a statement along the lines of “Pete’s blog is allowed to view this flickr photoset.”, not “here’s my password dude, do as you will”, or indeed “hey, IdP, see that service? That’s me that is.” I have to agree with Kim on the notion of impersonation - at no time should anybody give the required access level for impersonation of themselves, on or offline.

There be dragons.

Yes, it’s that time again. If you have any interest in seeing what has been going on, what is going on, and what is about to go on in digital identity I suggest you sign up for IIW2007 to be held in May at the Computer History Museum in Mountain View, CA. You won’t be sorry, but you might get caffeine shakes.

The Internet Identity Workshop (IIW) 2006B is next week, don’t forget to sign up. There should be some good identity selector demos in addition to the many interesting discussions. Oh, and coffee.

See you there.

I finally got around to checking out the support for information cards at Opinity. So off I go to grab Chuck Mortimore’s excellent proof of concept identity selector, install it on Firefox (an obscure browser used by long haired beardy folk) on Linux (ditto), create myself an information card and go acruising over to Opinity, click on the registration screen information card graphic, select my information card and I am greeted with:

You should use IE7 or above version to do this

Thanks for the heads up. Oh wait, Microsoft haven’t gotten around to releasing Internet Explorer 7.0 on Linux yet - I’m still waiting for the update. Did I get warped back to the 90’s? This had better not be taken as an exemplar for the first wave of implementation of information card support for the web 2.0 crowd. Or the web 2.0 crowd might find the first movers not movin because they can’t get in.

I suggest an alternative method of making sure the user does the right thing for themselves, upon receipt of an information card, use it, otherwise remain calm and ajax in Bob to explain what’s up. But whatever you do, don’t ever require a certain browser, browser version, or by extension, operating system.

Hopefully this example won’t last long.

Mike Beach is obviously a fellow who likes to ask the hard questions. This time he is asking how Higgins differs from a virtual directory. There is some level of confusion out there so in order to add a little clarity my answer would be that the difference is one of perspective and granularity. QED.

Well, I suppose I ought to explain that a little. You see, Higgins is either a lego brick or a gear stick. Which it is depends on whose favourite analogy you use, Dale’s or Kim’s. Dale might say it is a lego brick that you use to build other things, and Kim might say that it is a gear stick that works in a way we all understand because it works like other gear sticks. Or something like that. In any case, the point is that Paul Trevithick says Higgins is a framework. I suspect most would be happier with an explaination that it is a set of API’s for representing information about people along with the glue to connect one api to another and some other goodies like common schema. In object oriented pattern theory/design/voodoo it fits into the bridge pattern. Higgins is the bridge with the common interface to multiple systems. Yes, it’s a version of that lego brick that must also exist in virtual and meta-directories. So much for granularity.

Changing perspective lets get to the gear stick. Part of the Higgins project as a whole is to build a CardSpace like identity selector. Lets be clear - Higgins is the framework, the identity selector is one possible use of the framework. An identity selector requires a gear stick and Higgins looks like a gear stick. Of course, gear sticks don’t exist in a vacuum, they are usually accompanied by a steering wheel, a brake pedal, and an accellerator pedal. There needs to be a clutch pedal to aid gear changes and in some of the more luxurious gear stick implementations there will be a drivers seat right next to them. So, the Higgins identity selector is a bunch of co-operating parts that in some people’s blogs might look like a car, and the Higgins framework is one of the parts necessary to build a car.

Virtual Directories? Space ships, virtual directories are space ships with gear sticks. But that’s for another blog.

Ping Identity has re-affirmed what they were saying at the Digital ID World recently, that they will open source their Java STS code primarily for use by the OSIS project as a Managed Card IdP/SP Server. This is a welcome development that should help speed along various projects. Cheers to the guys at Ping.

Paul Madsen has spoken on the SAML Enhanced Client Profile and his verdict is it’s like a donut. Now far be it from me to contradict Paul and his immeasurable skills in producing professional looking diagrams, but perhaps he should note the words of Mark Wahl in his comment that it looks like it “might have a ‘hole’ at its very center where it does not provide coverage?”

Paul, I suggest using carrots. Nice high profile colour, tapered end useful for zeroing in on the axis position, no holes.

So, where is the digital you?

There has been a lot of focus on user-centric identity in recent months, but let us not forget about the identity metasystem. The identity metasystem concept is important because it recognizes that even if it is desirable for there to be one protocol that everyone speaks, to get there from here requires a pragmatic acceptance that there will be more than one protocol in the meantime. While choice is a marvelous thing in many situations, it isn’t something that the vendor relishes at the protocol level. When the customer comes calling must you turn them away because they speak OpenID and your software speaks SAML? Recalling my blog regarding the Microsoft Open Specification Promise, multiple standards mean your bolts don’t fit your nuts unless you buy them both from the same vendor. The identity metasystem must provide the necessary adapters so that different systems produced by different vendors on different platforms can at least understand each other, even if they don’t speak the same language.

One might ask who will be building the parts that make the system a metasystem. Clearly, one vendor who is doing that is Microsoft with CardSpace. However, one vendor a metasystem doesn’t make. To make the identity metasystem a reality it must come from multiple vendors, it must be ubiquitous, and it must be in the DNA of the platform. This is why open source efforts such as the Higgins project are so important, because they provide the means to make the identity metasystem cross-platform, cross-vendor, and cross-identity context. This might be considered the primary focus of the OSIS project as a whole - to make the identity metasystem happen. Red Hat supports the efforts of these projects and any project that works to make the identity metasystem a reality.

The correct answer to the question “where is the digital you?”

Everywhere.

Andre Durand has been blogging about the mash-up between user-centric identity and federated identity. His company, Ping Identity has put forward the idea of active versus passive federation. Active federation is essentially user-centric federation, and passive federation is the classic federation model where big business gets together and talks about us while we all watch the pretty pictures. In his recent presentation at Digital ID World, Ping CTO Patrick Harding had some great enterprise use cases where user-centric identity added the element of consent to the transaction, for example, access to a 401k account, or outsourced payroll services.

Now, while marketing must have its marketing phrases and there is nothing inherently wrong with active/passive federation, I think the rest of us might find the phrase consentual federation a little more descriptive. After all, consent is the major difference between the two. Oh, but what then to call the other type of federation… sneaky federation?

Next Page »