Great little “mashup*” event last night in London organised by midentity and BT. The advertised theme: Identity 2.0: my digital identity is an asset, but who owns it?
This is a huge topic so, predictably, the conversation was all over the place. This is no bad thing as these are issues that need an airing.
The demo of OpenID did not seem to convince the audience, despite Simon Willison’s undoubted command of the topic and the technology. (Remember not to fall into the same trap with even more sceptical audiences.) IMHO it could pass the “Mom test”.
I would have liked more discussion about balancing the issues of convenience, risk (privacy etc) and cost as people seem to jump onto one issue and ignore the others. Maybe a paper is needed to set this out. This is reminiscent of the early days of SOA (another large topic).
I’d also like to get into more discussion about preventing fradulent OpenIDs by requiring a tighter process around their issue. I will take this up with one or more of the OpenID Providers who we might want to recommend.
Now have the first implementation of an OpenID “Relying Party” (application) working on three of our own intranets. It’s been done in such a way that we can easily roll it out to more sites. What we learned:
- The API documentation took a little getting used to. This was all sorted out easily enough with the help of the code examples (in the Jan Rain libraries) and the mailing list where the doc was unclear.
- There are two mailing lists and the general one seems best for implementors of Relying Parties (just using library code).
- There seems to be a recognised need for multiple personnas that release different amounts of information to applications. In addition, some people want to run multiple identities to hide information about one personna from the others. I have been persuaded that this may not be just for nefarious purposes. This means that an RP user account should support multiple OpenIDs? Discuss.
- Concerns seem to center on Phishing rather than the underlying security of the protocols. There are numerous proposals to address this but the immediate takeaway is that we need to watch out for spoof ID Providers that might steal our credentials from our real ID provider. Several solutions have been suggested.
- Several new opportunities arise from OpenID. More on those to follow.
I’m going to Simon Willison’s talk next week and hope to get further up to speed as a result of that.
How many online logins do you have? I have 100s and until recently have not been overly concerned as many are not too important. However, there are a few which are essential and where I am not comfortable with the level of security. Like most people I use a small number of username/ password combinations so I can remember them. However, whereas I should change all of them frequently I only do that to those of the greatest sensitivity, leaving a residual exposure. As more and more critical systems are delivered over the web this risk escalates, as does the amount of effort needed to maintain sufficient security.
Possible solutions to this have been much discussed and it’s become clear that the right answer will be some form of user-centric ID system. This would allow me to assert that I am me and have a trusted third party back that up. Once that is established each application can grant me an appropriate level of access.
There are various technical problems with this but I believe they can and will be solved using cryptography. Much more important is the question whom do I trust to vouch for me and whom will my application providers trust to confirm my identity. The OpenID initiative seems to be the first one to address this in a credible way. Their set of protocols is independent of trust provider, application, implementation and platform. Implementations are being built and tested according to an open source model that gives the best possible chance of producing robust solutions.
In recent months we have seen some convincing developments in the establishment of these protocols as the defacto standard, namely the takeup by Yahoo, WordPress, Microsoft et al. There is already a critical mass of ID providers under this scheme. Trusting these will come with time.
However, the bigger issue is that of migration. Will the many thousands of applications using their own systems of usernames and passwords be prepared to embrace OpenID? It will, of course, depend on user demand and the cost of conversion. Wondering what it would take to do this caused us to think about migrating some of the applications we have created for our clients. So we are mounting a project with the following objectives to guage feasibility:
- Easily convert existing web applications using basic authentication to use OpenID
- Allow users to migrate at their own pace by supporting two alternative forms of authentication simultaneously
- Retain the facility to jump into protected parts of the application at any URI, including parameters
Watch this space for a report on how this goes. Initial indications are that this will be straightforward, thanks in no small part to the availability of proven open source libraries on which this project will be based. An additional module will be created. This will be designed to plug in with minimal change to any application using username/ password on a LAMP platform.