Open Identity Pilot For Open Government Announced

Drummond Reed the Executive Director of the Information Card Foundation and one of the DataPortability Project’s early advocates and current Steering Committee member dropped me a note this morning with some great news coming out of Washington DC, in regards to various vendors working together on a Pilot for Open Identity for the Open Government imitative . The full press release can be read here: Yahoo!, Paypal, Google, Equifax, AOL, Verisign, Acxiom, Citi, Privo, Wave Systems Pilot Open Identity For Open Government and Drummond has promised us a post from the ground on this important announcement!

“Open government cannot and will not compromise either security or privacy,” said Drummond Reed, Executive Director of the Information Card Foundation. “By working with private industry, the U.S. government is harnessing the innovation and efficiencies of the open market and letting citizens choose their preferred means of engaging with government agencies.”

Congratulations to Drummond and the rest of the participating organizations, vendors and individuals who are leading this charge!

It is great to see the US government is working towards a user-centric model, one where people are in control of their identities and are not owned by any one organization. Our own DataPortability Project ToS/EULA task force has been busy at work all summer creating a range of standard portability terms and license clauses that will improve communication between people and service providers. Over the next few weeks we will be publishing more information on this and solicit additional feedback to incorporate into the final versions.

Lobby against the password anti-pattern

Back in January, I wrote how it’s time to criminalise the password anti-pattern. The password anti-pattern is where service A requires you to enter your service B username and password so service A can act for you with your B service. It teaches you how to be phished, and the only way to resolve it is to change your password. It’s also no longer necessary as lots of sites now have OAuth support, including Twitter.

For example, popular service TwitPic requires you to enter your Twitter username and password in order to access the service. This is an example of the anti-pattern that needs to be lobbied against.

A service that does it right is 140 Mafia, that uses the Twitter implementation of OAuth – it allows you to link the two services together with your permission without having to give over your service B password to service A.

Tom Morris now maintains a list of services on Twitter that catalogues services that continue with this anti-pattern. Encourage them to switch to the open standard OAuth or just avoid ‘em. For Data Portability to exist, service providers have a responsibility to be mindful of your privacy – and they should not insist on you handing over your password to other services.

Forget Open Standards

Forget Open Standards…

Well, sort of. To date, the DataPortability project has often referred to its vision as “Open Standards based Data Portability”.

The problem, though, is that people don’t get why Open Standards are so important. Some even think that we’re advocating open standards for the sake of open standards. In truth, Open Standards are just a means to an end. It’s time the community started to focus on the end, rather than the means.

The end is not “Open Standards based Data Portability”. Rather it’s what I’m starting to call ‘Peered Data Portability’.

Peered Data Portability differs dramatically from what we have today from Facebook Connect. Here are some diagrams to explain:

FB Connect Version of data portability - Hub n Spoke

The Future of Data Portability - Peered Nodes

Does the peered model look familiar? It should

The Internet is already a Peered environment

In the Hub and Spoke model, a single node controls the transaction and facilitates data sync between participating 3rd parties. This is efficient and always the quickest and most commercially viable way to get the job done (at least for the central node).

The problem, however, is that it has a central point of control, failure and commercialization. A monopoly, or market confusion, is inevitable. At the very least this model leads to reduced innovation along the connections.

Can you imagine if there was only one Web server? One FTP server? One Email server? Companies like Google would have certainly never been allowed to exist. They might have been sued by the Acme Web Server company early in their life much like Power.com is being sued by Facebook today.

The peered approach, is much more analogues to the web itself. It lets a thousand flowers bloom as equal participants in an open ecosystem. It allows and incentivises innovation at all the nodes. It also means that the solution is not a commercial product, but rather part of the fabric of the web itself, much like HTTP is.

Sure, Open Standards may facilitate interoperable peering, but that’s just a technicality along a much bigger journey. So while Open Standards are important, they are certainly not the point. Standards come and go (and some stick). The peered, web-like nature of the Internet will outlive us all.

It’s time to move the conversation up the intellectual stack.

I look forward to the continued emergence of Peered Data Portability.

Note: This is a follow up to my ‘Forget Facebook’ post last year. I don’t mean to pick on Facebook, but their first mover status provides a clear counter-point.

Time To Criminalize The Password Anti-pattern

Update: Twitter made another commitment today to adopting OAuth which is great! However they acknowledge that it won’t solve all problems (like we argue) – nevertheless these are positive steps to us eradicating the password anti-pattern

In case you’ve never heard of it, Twitter is a micro-blogging service that is doing to communications what search did to information. It has exploded in popularity, and whether they find a revenue model or not – their impact is permanent and is leading the way for a new era of communications. I am one of their biggest fans and want to help them succeed. But I feel with their growth, propelled by loyal users like myself, we ought to let them know there are things that concern us.

The biggest issue is that whilst they enable data portability, they are doing it in an insecure way. As Chris Messina said, lets make 2009 the year we see the end to the password anti-pattern. In this post, I will explain what that anti-pattern is and a way we can fix it. The biggest reason why Twitter is continuiing with this anti-pattern (from my eyes), is because it’s a usability issue. But as you will see me prove below through screenshots, it isn’t. Just think of having a PIN code on your bank card: that’s a usability issue as well, but y’know, one of those good usability issues.

Twitter and Security: all we’ve heard in 2009 so far
Twitter is used to constant free PR, but this year two separate events occurred that could have been non-events (if they do what we ask).

The first was a third-party that provided a feature people wanted. As Twitter has an Application Programming Interface (API), third-party’s can create mashups and therefore provide this functionality to Twitter users. However because Twitter does not support delegated authentication, you need to enter your username and password. There are hundreds of third-party applications like this, and most are safe (we hope), but this particular site within 24 hours had put itself up for sale! And people couldn’t turn off the service – they had to change their password to do so.

The second incident to occur this last week, was an attempted phishing. Apparently, some users were being sent private messages telling them to visit a certain site which compromised their security. It’s ironic that Twitter tells you to not “share your private info” but for you to get value out of their API for mash-ups and third-party tools, that’s exactly what you need to do – and it makes situations like this slightly more risky.

Fortunately, there are things that can be done to minimize the risk of your accounts getting hacked, and for you to never have to give up information about you that will compromise your security.

Delegated authorization
There is a solution to this situation. It’s free to support it, simple to use, and in fact – Twitter’s team inspired its creation the other year. It’s through the use of an Open Standard called OAuth. There is plenty of material you can read on the web about this and a good start is Eran Hammer-Lahav’s explanation of oAuth followed by his three-part series for beginners if you want to dig a little deeper.

The basic concept is that it allows you to delegate authorization for use of an API. Huh?

I’ll illustrate this with an example. Let’s say you come across a Cool Product that allows you to do something unique with your Twitter account (say, being able to stream your Tweets through your e-mail client rather you having to visit the Twitter website). As this Cool Product has no formal links to Twitter, for you to use it, it needs to pretend to be you. Therefore, it asks for your user name and password. It knocks on Twitter’s API door, pretending to be you, and the Cool Product then gets access to your account to do the stuff you want to do with this third-party application. The problem with this approach, however, is that they can knock on Twitter’s door anytime pretending to be you – even when you don’t want them to.

With OAuth, it would be very different. Instead of you needing to provide your username and password, this Cool Product will say “Hey dude, I need to get some permissions – click this link to give it to me”. Then a request will be sent to Twitter’s API and Twitter will send you to a screen saying “hey dude, these third party dudes want access to your account – you cool with that?”. Then, with a simple click of the button, you can approve or deny access. Once approved, the Cool Product can then function – and you didn’t have to give up any private information like your password.

Here are some screen shots between another innovative start-up called FriendFeed and Google (who supports OAuth).

In this scenario, I want to add some more friends on my FriendFeed account. So I click on the option to invite them

When I click on “import from Gmail”, instead of having to type in my username and password to access my contacts, I simply get redirected to a screen. And because I’m permanently logged into my Gmail account, I don’t need to do anything else other than read and click “grant access” (otherwise, I would need to enter my Google credentials).

.

Easy! Compare this to Facebook, another company that needs to think more proactively about its users security. If I want to add friends to my Facebook account, instead of redirecting me to the Google servers where I can grant access, it asks for my password.

Next steps
As people on the web using web services, we’ve been forced to give up confidential information to get the value out of a service. We’ve forced ourselves to be okay with it with the sites we trust, but there are plenty of brands out there we don’t know to trust. But the thing is, this isn’t something we need to trust anyone with. With our health records and financial records accessible online, this isn’t just a matter of reputation risk but one of genuine identity risk.

There is a solution to this problem, and now that you recognize it, demand web services to give you data portability in a secure way. Let’s make 2009 the year that we kill the password anti-pattern. While easier said than done, it’s a fix that will curb some of the security issues: we hope Twitter hurries up in changing their API to require OAuth.

Twitter – we know you’ve been meaning to do it, but hopefully you really mean it this time. Because quite frankly, we as users are fueling your growth and the promotion of your API without some sort of safe-guards like this, is irresponsible (especially as these attacks prove you are going all the more mainstream. I don’t want to tell you how to run your business – it doesn’t have to be OAuth – but for crying out loud, give us some security for our digital identity.

One final Big But
Twitter has strong arguments to not jump onto OAuth, some of which they’ve said publicly and some that I think might be issues. They certainly have a competent team, and whilst they know the benefits, they also understand the fact that jumping onto OAuth or any type of delegated authorization will not fix all problems. However it’s a start. Here are some issues:

1. OAuth is only good for services over web browsers. It is a real pain (or virtually impossible without some hacks) to use it for the client side (ie, on the desktop) and mobile sites – both of which Twitter has a lot of users that use it this way. The response to that is that some security is better than none – it’s not a big deal that users will have to authorize applications via the browser (and Twitter can just point a hairy finger at the standards community so they can fix it). At least give users the option to determine how secure they want to be.
2. Twitter will need to support multiple authentication systems due to the limitations of oAuth. This is a real issue, but not an impossible one to manage, and the community is certainly willing to help out. My main point is that this is actually a security issue that matters, and because the cost is borne by the users and not the company, it’s not given equal recognition.
3. The user experience will suffer for users. Well the reason users will “suffer” is because now, instead of just entering their password, they will now have to click a few buttons on different screens. As the screenshots show above, the user experience is not affected that much and I think while a valid point, it’s more a “different” user experience
4. The user experience will suffer for developers. Yes it will, because instead of the lazy option to just ask users to hand over their password, they actually have to write some code to get the appropriate permissions happening. But this is a core reason why the DataPortability Project supports widely-supported Open Standards, as it minimizes the costs to business: once a developer learns it once, they know it for all future application development.  And like I said above: a bank not puting a code on your bank card, is more painful for your bank, but better that pain than the option without which poses risks for users.
5. It will not prevent phishing.  Lachlan Hardy gives a useful explanation on why (notice all Australians give the best explanations ), as theoretically, people will be more prone to phishing attacks because of the ease. This is a valid point, as people potentially will just blindly click away to their doom, but let’s also remember there will also be a lot more control. A site can monitor suspect services to alert users, there is a full digital paper trail, and a user can revoke their authorization at any time. Certainly a bit of control is better than none, and by reducing the weak spots in the chain, more targeted efforts can be made to ensure users’ security is no compromised.

The “why” of Open Standards

There’s a great book that you need to read if this whole data portability world perplexes you, called Wikinomics: How Mass Collaboration Changes Everything by Don Tapscott and Anthony D. Williams. Suffice to say, it’s one of those Must Read books, but what I want to share is a story the boys wrote that clearly illustrates one of its central theses.

Hurricane Katrina ripped into the coastlines of Louisiana, Mississippi, and Alabama on Monday, August 29 2005 causing more human misery and economic damage than any storm on record…

…Yet, out of the chaos, and in the face of official ineptitude, came a powerful story of how an ad hoc team of volunteers from across the country came together to concoct an information management solution that far surpassed anything the local, state, and federal response teams had mustered. At the heart of the volunteer effort was a central repository of survivor information called Katrinalist. This impromptu Web site compiled survivor data from all over the web into a searchable format that made it easy to identify and locate friends and family members…

The story goes onto say all this valuable data to capture relevant information for each person (name, location, age) was collated into a central database and that the team behind this PeopleFinder project even created an open data spec called the PeopleFinder Interchange Format. The big challenge however, was being able to scrape information from a bulletin board which typically read “My father Joe was working in New Orleans and hadn’t evacuated. He was living in Jefferson Parish. We don’t know if he’s okay. Please call me or Mom in Houston. Lisa Brown, Houston, TX.”

What occurred was volunteer efforts to manually enter data into the database, of which thousands of people later did. But there could have been a dramatic difference if there was an agreed upon standard for collecting and sharing data. Imagine if Facebook decided to participate, to allow certain details to be linked to a central identity, which could then be linked to all the data collected by the relief agencies like the Red Cross. We would have interoperability of data, minimizing effort and creating time for potentially time critical information.

Having organisations storing their data in a certain format to export and access, is not killing their competitive advantage (I would argue it helps it). And if people understood the value of Open Standards, which heaven-forbid another disaster of this scale occurs, the power of the Internet can be unleashed to potentially save some lives.