Some commentary on John Fontana’s recent article on this topic. First, I wanted to give John some credit for saying (below) that the basic structure is to have a trusted identity provider but, as he states, there is still a single point of failure argument.
The very basic structure is to have a trusted identity provider (IdP) that vouches for you when other sites -known as relying parties - go looking for your authentication credentials. Nearly every site gets out of the password game - LinkedIn, eHarmony, Last.fm, etc. etc. and the number of IdPs shrinks to four or five major sites.
Yes, there is a single point of failure argument, but liability contracts are the incentives IdPs have to protect your data. Protecting your identity will be their core competency as opposed to holiday cheese balls and wrapping paper.
An interesting analogy of this was my drive into Seattle today. It’s June 26 and it’s 56F and raining. What a crappy day for summer. But, as I was crossing the 520 bridge, there was a mature bald eagle sitting on a light pole just above the road. What a sight to behold. Unfortunately, I think we are going to be in 56F and raining weather (passwords) for a while with the occasional bald eagle (IdP) seen in-use to brighten our day.
Secondly, I wanted to state that passwords aren’t dead. Until every IdP is SUPER EASY to install and operate passwords and password synchronization will live long into the future. And yes, there will ALWAYS be the potential for a single point of failure. How do you protect against that? Redundancy and protecting the keys to your kingdom with two-factor authentication (like Quest Defender).
And finally, let’s not forget that in order to use an IdP in this brave new world your application must be written to support (federated) claims. No re-write required for password synchronization or to continue to use in-app passwords.
I agree with John that it is time to change the movie but few seem to be ready to pay another admission charge. At least not at the moment.