Currently, the most familiar social Web standard is OAuth2 from the IETF, widely used for open authorization (which allows us to give second-party Social Web services access to information without asking for a Gmail password) on sites such as Facebook and Twitter. However, it now appears there may be a number of other standards in the wings, ranging from work in browser-based identity to rolling your own Google+'s Circles in a federated Social Web to emerging work around the hot topic of social business.

Remember how FireSheep let even your mother hijack your Twitter account? Dirk Balfanz (Google) explained how shared secrets could be fixed by binding their verification to good old fashioned cryptography in HTTPS. Finally, Ben Adida of Mozilla pushed for a new approach to identity called BrowserID, which lets the user agent's client, rather than Facebook or any other big server in the Cloud, serve as a proxy for the user's identity in social sites. Out of the argumentation, it seems that soon a common Web Cryptography API will be happening at the W3C.

Remember Diaspora? Over the last few years, Diaspora, StatusNet, and others have been hard at work developing a stack of specifications loosely grouped together under OStatus to make that dream a reality. These specifications allow anyone to roll their own Twitter or Facebook clone that "federates" status updates in a decentralized manner, an effort the W3C is supporting in the Federated Social Web Incubator Group. However, up till now all these specifications allowed only public updates. Yet with the advent of Google+'s Circles, private status updates were clearly next on the agenda but how could those be done in a decentralized way? Then Blaine Cook, former lead-developer of Twitter and originator of OAuth, proposed a tentative solution called "Dialback" that resurrected the obscure HTTP "From:" header and OAuth-style shared secrets to allow private "circles" to be decentralized as well. Several Google+ engineers were in attendance with their product manager Joseph Smarr (originator of the PortableContacts specification when he worked at Plaxo), and while far from revealing any product secrets, a standards-based federated social Web is likely to be their own agenda. Being able to find users on Google would definitely make joining a service like Diaspora less lonely!

At the final session, a number of companies threw down their cards. Representatives from Boeing discussed how they would eventually like to have their own internal social network join others on an ad-hoc basis through a federated social Web. The Open Mobile Alliance (a coalition of over 140 mobile providers) discussed how they were also planning on rolling out a federated social Web client. However, there was concern from some that the underlying technologies could be patented, which would prevent their roll-out in products. This would be prevented if they were released under a license like the W3C Royalty-Free License.

Monica Wilkinson (now of VMWare, which bought her successful social startup SocialCast) showed that the ActivityStrea.ms specification had done this with the Open Web Foundation. However, becoming a W3C Community Group would have made the process much simpler by requiring a commitment when joining the mailing list. At the conclusion, it appeared that many of the specification efforts were going to go for light-weight Community Groups in order to help sort out any intellectual property issues.

The next steps for the W3C in this space are to gauge interest from the wider market in standardizing around the social Web, and this requires sharpening up business use-cases. So starting today, 8 November, the W3C is organizing its first ever virtual event, the W3C Social Business Jam from 8-10 November. This event will use IBM's "Jam" software to help gather ideas and requirements around standards for social business, ranging from identity management to social metrics.

So if you missed the W3C Technical Plenary, Tim Berners-Lee, Evan Prodromou, Monica Wilkinson, along with Doc Searls and Yochai Benkler will be online during the Jam in order to chat about the future of the social Web. We look forward to hearing from you.

When users authorize to a third-party app for the first time, they'll see a new permissions screen detailing what that integration with Twitter means. This can include activities like reading tweets, seeing who the user follows, tweeting on a user's behalf, or accessing Direct Messages.

Then at the end of the month, those apps that needn't access DMs will no longer be able to do so.

An Oft-Requested Change

According to Twitter, this change has been something both users and developers have long been asking for. But until now, developers have not had granular control over the content they could access, unlike for example apps on the Facebook platform. With Twitter, it's been all or nothing. Users have had to hand over the keys to all these activities when authorizing a new app, something that might make them uncomfortable when just trying out a new service.

Tim Haines, founder of Favstar.fm which allows users to keep track of Favorited messages, says that "As an app developer, I'm happy for this change." Favstar doesn't need DM access, so he's happy to opt out. He hopes that by being able to assure users that the app doesn't access their private messages, that more users will be likely to sign up.

New Permissions for Apps that Access Direct Messages

But now there is a new permission level called "Read, Write, & Direct Messages," according to Twitter Developer Advocate Matt Harris. If an app does require access to this permission, developers will have to make some changes and will have to use OAuth, not xAuth. "To ensure users know that an application is receiving access to their direct messages," says Harris, "we are also restricting this permission to the OAuth /authorize web flow only."

This change might put some pressure on developers of iPhone apps that will have to hustle to update and resubmit for review. The change might also make the user experience on mobile apps a little more awkward as users will be prompted through the webflow that xAuth currently avoids (and by extension, this might make Twitter's own mobile apps seem much more slick).

Applications that don't need to read direct messages won't need to make any changes, and users of these apps won't notice anything different when these permission levels change.

Twitter has taken to redesigning the OAuth screen - the screen you see whenever you decide to login to an application using your Twitter account - in an attempt to better show what you are agreeing to when you hit the "Allow," err, "Authorize app" button.

Twitter developer advocate Matt Harris announced on the developer Google group this afternoon that they were working on refreshing the screen to offer "better clarity about what an application can see and do with an account." Though it might be better than before, it's still missing one key thing - the fact that the app can access your DMs.

Twitter developer Orian Marx points out, however, that a few key permissions are omitted from this screen: the ability to unfollow users and, more importantly, access their private DMs.

"Obviously it's been to everyone's benefit who has built apps that rely on OAuth up to this point that there has been specific mentioning of access to DMs as this would likely turn off a lot of people from granting access to experimental apps," writes Marx. "The reality is that the OAuth system needs finer-grained controls."

While Facebook allows developers to select what content to request authorization for, with Twitter it's all or none. By giving a Twitter app access to your account, that includes everything mentioned above - including those DMs that you might have thought were totally private. This isn't the first we've heard of this - GigaOm's Mathew Ingram pointed out last October that DMs aren't exactly private, but it seems notable that this fact might not show up on the new login screen. Or maybe they will.

Harris responds to Marx on the developer list, writing "This is a first release of these pages to get a feel for if they are going in the right direction. We tried to select a number of phrases that explain the access that's being granted to an application but that are also easy to understand. I think there will always be some that don't make it, but there are others, like the ones you raise, which would help aid transparency more."

Here's hoping that either users are made explicitly aware that their DMs are not exactly private or that developers are given the granular security permissions necessary to say "No, we don't want access to that." Or both.

Image via @abraham's Picassa.

According to a Gartner survey earlier this year, enterprise managers see identity management as a top business priority. That would lead to the conclusion that enterprise operations are considering a variety of identity management options.

Emerging is a growing interest in social identity as a means for employees to sign into external applications.

More so than ever before, companies are using social technologies for a variety of purposes - such as using Facebook as a customer service environment. Social identity serves as a way to manage all the various sites where people connect as part of their work.

Two examples include Facebook for Websites and Twitter, which uses OAuth, to verify the identity of the user. We are in the early stages but Facebook pages are pretty common so you can see why an enterprise may use it for employees to connect with third-party sites.

There's another reason why social identity may have a lasting future. Federated identity has really not been adopted, leaving an opening for services with a social component.

It's not that OpenID is going nowhere: Google Apps uses OpenID; it has been adopted to some extent by the federal government. But it is not nearly as popular as Facebook or Twitter.

But, still, these are very early days. And the issues are numerous.

Dion Hinchcliffe wrote on the topic earlier this year:

"Instead, off-premises SaaS and cloud computing offerings are offering basic synchronization with LDAP and other corporate identity repositories. Also becoming more and more important is identity authenticity (which Twitter tried to address with Verified Accounts). Watch for a raft of social identity issues to accumulate and for new enterprise open identity solutions to attempt to address them as our identities on the Social Web increasingly compete and conflict with our enterprise identities."

Organizations are a long way from adopting social identity systems. OAuth 2.0 represents a first step as it automatically connects services. But there are other options, too.

Over the past several months I've had conversations with Eve Maler, one of the most authoritative voices about identity management. Eve is the chairman of the User Management Access Project Workgroup (UMA). UMA is proposal-as-a-service that would act as an intermediary platform for managing identities across social networks, SaaS providers and other services that the individual is responsible for managing. It gives more control to the user, who provides consent through the service.

Phil Hunt writes:

"Where in the typical OAuth 2 deployment, user authorization and resource owner authorization are combined, UMA instead separates the processing of a user's consent, from authorizing access by the resource owner (e.g. Flickr)."

Aside from the benefits Eve describes, here are a couple more things I like about the UMA proposal.

• UMA recognizes that user information exists in many places on the Internet, and not just at a single IDP/OPs etc.
• It supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems.
• It's a great way to separate the issue of user consent away from the resource owner's access control policy.
• It becomes possible to handle consent when individuals are offline.

Maler made the following point in response to Hunt:

"In the enterprise, an externalized policy decision point represents classic access management architecture, but in today's Web it's foreign. UMA combines both worlds with the trick of letting Alice craft her own access authorization policies, at an AM she chooses. She's the one likeliest to know which resources of hers are sensitive, which people and services she'd like to share access with, and what's acceptable to do with that access. With a single hub for setting all this up, she can reuse policies across resource servers and get a global view of her entire access landscape. And with an always-on service executing her wishes, in many cases she can even be offline when an access requester comes knocking. In the process, as Phil observes, UMA "supports a federated (multi-domain) model for user authorization not possible with current enterprise policy systems."

Social identity makes sense for its ease of use. It fits with trends we see in the enterprise. The big question is trust and the implementation of infrastructures that provide a secure and simple way to identify the individual on the network.

In all, UMA may be a better answer for unified identity control across the enterprise and the Web.

As Champion points out, Twitter developers are currently only given two choices for access permissions: "read-only access" or "read & write access." Read-only access obviously restricts developers to doing nothing more than access a user's timeline without being able to manipulate it or post anything in the user's name. Read-write access, however, gives a developer total control over a user's account. With this, a third-party app can tweet in your name or follow and unfollow other accounts.

Access to Direct Message

Most importantly, though, this setting also allows developers access to your direct messages - the one part of Twitter where users rightly expect the be able to talk over a secure private channel. Here is what Champion has to say about this:

Direct Message Privacy - Do you consider your DMs private? People increasingly use DMs like short emails or IMs and assume it is a private channel between two people. In reality any app you have granted access can read all of your DMs. As an example, if you can get Michael Arrington (@arrington) to try your site and use Twitter OAuth you can now read all of his DMs. That might be tempting to an unethical few. And the challenge to Mr Arrington would be to even know that they were read without his permission. Twitter would have the logs of the API calls, but how would he know it happened? Or which app to revoke if he suspected it?

As Ryan Paul noted earlier this month on Ars Technica, there are some inherent problems with both Twitter's implementation of the OAuth authentication standard and OAuth itself. Leaving these questions aside, though, Twitter clearly needs a more fine-grained permissions structure (something that Facebook already offers). Why, for example, can't you tell a third-party app that it's ok to post to your stream, but not to access your direct messages or follow list?

Note: We asked Twitter for a statement and will update this post once we hear back from them.

At 8 a.m. today, Twitter shut down basic authentication forever and, if your Tweetdeck or other Twitter app doesn't work, there's likely something you can do - update.

Twitter notes in its blog post that you can always review what applications you have granted access to your account by looking at the Connections section under your settings. If you haven't updated to the latest version of a Twitter app, you may find that it is broken and need to update for it to continue working.

As we explored when Twitter first started testing OAuth as a solution to its security woes, with this new system you will never have to cringe and give your Twitter password out to a stranger again. Another way to say that might be, never hand out your Twitter user name and password, ever again, as this switchover negates that process. And while it makes everything more secure, you'll want to be aware that clicking "approve" means you're giving that app carte blanche, read/write access to your Twitter account, so you should still weigh whether or not you want to give that particular application access before saying okay.

As for developers, the transition to OAuth from basic authentication has been a long time coming, with multiple emails sent out in the developers' group, so many apps are already using the new system. If you have somehow missed all the hubbub over OAuth, then that's what's happening, and Twitter will no longer allow third-party apps to use basic authentication.

In this world, keeping up with all the work in the community itself is a feat in itself. As proven recently, even aligning the naming of standards in our small community (xAuth, XAuth) proves challenging enough. With that said, we'll share we what we've learned about this version and what work has been incorporated into it.

The OAuth Working Group in IETF generated a first draft of OAuth 2.0. This group that is credited with this document consists of active leaders of both the Twitter API team as well as Facebook community standards team. A robust number of daily discussions are happening in the working group hosted at IETF include topics such as the default use of JSON that show the opportunity and challenge of growing the standard from a web-based to a broader set of devices and scenarios.

One of the stated goals of the IETF OAuth working group is to maintain backwards compatibility with OAuth 1.0. From our sampling of the depth of change in scope and conceptualization of the standard, this may be a big deal for the group, especially if key members decide to legacy their support for the first versions.

As part of the evolution of OAuth, there is the case of the OAuth WRAP Google Group. This group has forged ahead to develop profiles for scenarios seen as extensions to the profile OAuth 1.0A. This includes new ways to gain tokens bringing the use cases of Javascript or RIA applications. WRAP also redefines the dependency on SSL and provides a simpler way to get started using tools easily accessible to the web resource. With some changes noted, this work has been brought forward in the OAuth 2.0 public draft.

David Recordon, a chief thought leader in the open web (also employee at Facebook) recently offered this summary "What's going on with OAuth?" to help align the understanding of the evolution of the standard.

Here we show one of the better known descriptions of the OAuth flow as provided by Yahoo. The annotations show a few of the areas that are under consideration for changes in OAuth 2.0 and/or in the work done in the OAuth WRAP group.

Last week, at Twitter's Chirp '10 the Twitter API team gave this presentation, "Too many secrets, but never enough: OAuth at Twitter". This document contains overview of the basic process of Twitter, commitment to the movement to OAuth 2.0, and discussion of Twitter's xAuth and OAuth Echos projects.

Twitter Likes to Optimize

Twitter is deeply intertwined with the inception and direction of OAuth. The company is both involved in the specifications but also is a lightening rod for discussion in the development community. In the Twitter blogs and developer groups, OAuth is being considered deeply in the trade-offs in implementation, design, and risk in the Twitter ecosystem.

A few areas under discussion is how to remove the re-direction from the process, and also how to keep a running log of all account client accesses available to the user as a way to make sure users are aware and signaling proper account use.

The Twitter API team has been willing to make change happen in the community by deprecating legacy processes, such as basic auth. With the changes coming in OAuth 2.0 the company may be in the best position to bootstrap developer adoption of the new standards.

In this way, OAuth 2.0 need to adapt to the speed and need of the Twitter use cases, to avoid becoming like XML. XML is a good thing, of course, but when push comes to shove, JSON is lighter weight and more compact. This is helping it become the preference for data attribute exchange in APIs like Twitters that support OAuth.

With the rise of the social ecosystem as the hub for authorization, it is becoming clear that the IETF efforts need Twitter as much as Twitter needs the IETF. This seems like a good balance that will guide use cases along the way to practical standards formalization.

There are a lot of questions out there about OAuth 2.0. Top of mind is whether this technology release will see the effective join of Twitter, Facebook, and Google? Or, will the practical matters of business and strategy keep the standards intact, and the implementations as islands?

What is your prediction for OAuth 2.0 and web resource authorization?

What does that mean? It means mashups based on the actual emails in your inbox. If you've given a 3rd party app secure access to your Twitter account, then you'll be familiar with the user experience. The first example out of the gate is a company called Syphir, which lets you apply all kinds of complex rules to your incoming mail and then lets you get iPhone push notification for your smartly filtered mail. Backup service Backupify will announce tomorrow morning that it is leveraging the new technology to back up your Gmail account, as well.

People are often wary about the idea of giving outside services access to their email, and well they should. OAuth is designed to make that safe to do. Combined with the IMAP/SMTP email retrieval protocols, it gives an app a way to ask Gmail for access to your information. Gmail pops up a little window and says "this other app wants us to give it your info - if you can prove to us that you are who they say you are (just give Gmail your password) - then we'll go vouch for you and give them the info." The 3rd party app never sees your password and can have its access revoked at any time. You can read more about OAuth, how it was developed and how it works, on the OAuth website.

Why is this so exciting? Because it means that the application we all spend so much time in, where so much of our communication goes on and where you can find some of our closest work and personal contacts - can now have value-added services built on top of it by a whole world of independent developers, without your having to give them your email password.

That's the kind of thing that the data portability paradigm is all about. It's the opposite of lock-in and seeks to allow users to take their data securely from site to site, using it as the foundation for fabulous new services. Google says it is working with Yahoo!, Mozilla and others to develop an industry-wide standard way to combine OAuth and IMAP/SMTP.

See also: Rapportive - an incredible GMail contacts plug-in.

"We really want to get people to switch over and stop using Basic Authentication when talking to our API in a production manner," he writes. "Why? Basic Authentication is, simply, horribly insecure."

Here's the problem, as Krikorian describes it:

You're an OAuth enabled Twitter client, and you've already authorized your user. You user wants to use a media providing service like TwitPic. TwitPic, currently, asks for the username and password of your user so it can store the photo on behalf of the Twitter user. You don't have that username and password, so how do you give the ability to TwitPic to verify the identity of your user?

Krikorian is proposing a solution he calls "OAuth identification delegation", wherein the application your using, Tweetie in his example, passes along its OAuth authorization to TwitPic, which TwitPic can then use to verify its actions as authorized. Right now, using TwitPic requires you to enter your user name and password separately.

For now, he says the idea is still in development, writing "once I think we've come upon the best solution, I'll write this up more formally, as well as port it to OAuth WRAP/2.0 (where Twitter is headed)."

Krikorian included a diagram of his solution and is soliciting feedback on his blog.

OAuth Identity Verification Delegation Example Workflow v0.2

Sarver also noted that 50% of the company's traffic now happens on partner sites and through applications. For Twitter, according to Sarver, it's all about growing the market and building out the ecosystem. Throughout the keynote, Sarver stressed that Twitter can only be as successful as long as its developers are successful.

Sarver pointed out 3 companies that have manged to monetize Twitter: CoTweet, OneRiot and TweetMeme.

Coming Up: More Transparency, Improved Communication and a Business Model

Going forward, Twitter wants to offer even better tools for third-party developers in its ecosystem. Twitter wants to be more transparent with its developers and improve its communication. In addition, the company wants to improve the utility of its API. Twitter also plans to announce a business model that allows it to share in the success of its partners.

Everybody Gets Access to the Firehose

Most importantly, Twitter is opening up the firehose of tweets to all developers. Sarver didn't announce any details, but this is obviously a very important move as it will give more developers the ability to build applications that need real-time access to every tweet without having to get Twitter's permission.

Soon, developers who use OAuth will be able to ping Twitter more often than services that still use Twitter's old authentication mechanism. Twitter will soon deprecate its old non-OAuth authentication mechanisms. In addition, Twitter will launch an API for browser-less apps.

Twitter also plans to launch a new developers site to educate its developers and will soon host its first developers conference.

Image credit: @scobleizer.

As long as people are willing to trust their Twitter log-in information to third parties - and don't look carefully at URLs before they log into websites - and as long as a small number of bad actors want to pee in the social media swimming pool, this kind of thing will continue happening.

Apparently there's no substitute for ruthlessly and constantly policing your own feed, thoroughly investigating services before you sign up for them, double-checking the URL every time you are about to enter info into a form, and regularly purging your OAuth settings of services you no longer use.

Also, to be safe, change your password regularly... you don't have to be obsessive about it: every three hours or so should be enough. And because erring on the side of caution is always a good idea, fake your own suicide and change your identity at least once a year.

And you thought Twitter was going to be fun? Slacker.

More Noise to Signal.

Just last week, MySpace also announced that its users can now sync their updates with Microsoft's Live profiles. For now, the new two-way sync feature only works with Twitter, though the company notes that it will soon support other networks as well.

AOL also just announced two-way syncing with Twitter when it launched its AIM Lifestream service last week.  Overall, these services aren't very earth-shattering, but it is good to see that MySpace continues to open up and create more links with other services.

It's also becoming increasingly clear that Twitter is now the de facto clearinghouse for status updates. Pretty much every new service that features status updates already pushes updates to Twitter and now most of the older services are also (slowly) coming on board.

At some point in conversation Hammer-Lahav realized that the problem went far beyond the Twitter implementation. The OAuth protocol had an inherent vulnerability; big companies like Google, Netflix and Yahoo had implemented OAuth and scores of tiny startups had too.

The Nature of The Problem

The problem was a vulnerability to something called a "Session Fixation Attack." The gist of it is this. Services supporting OAuth let their users pull data into other websites for reuse around the web. In order to do this securely, the 3rd party site has to ask the original site for permission. This might be a new little website asking permission to import your Gmail contacts or to post to Twitter through their site instead of Twitter.com. OAuth was born from the work that Flickr did to create a secure way that other applications could be granted permission to access your photos for printing, editing or posting elsewhere.

The problem arose if an attacker could convince you to complete their request for account permission with your login. At the end of the process they would have access to your account.

Hammer-Lahav explains how this works in detail and offers flow charts in his blog post explaining the technical nature of the problem. For another explanation of this kind of attack see Mitja Kolsek's paper titled Session Fixation Vulnerability in
Web-based Applications (PDF), which was published in 2002. In other words, this is not a new problem - it was just newly discovered to be an OAuth vulnerability.

How It All Went Down

Eran Hammer-Lahav was at FOOCamp when he realized this was a problem that extended far beyond Twitter's implementation. All 30 companies currently offering OAuth were vulnerable. MySpace, Yammer, PhotoBucket. Google, Netflix, Yahoo. Millions of peoples' accounts were at some risk.

If OAuth was software, a fix could be implemented and pushed out to everyone who was using it. But it's not, it's just a standard-based specification implemented out in the wild and no one party is in charge of it. Someone had to do something though, and they had to do it fast.

The first thing Hammer-Lahav decided to do was call up Alex Payne, API lead at Twitter. Though Twitter had done everything right, it was a particular Twitter implementation that revealed the whole problem and it had only been out for a few days. (We thought it a big enough deal that we wrote a whole post about that implementation.)

Twitter shut down the OAuth option for login within 30 seconds of his phone call, Hammer-Lahav says. They did it without explanation, because they were asked to keep quiet about the security problem for one week - in order for all the providers to get a chance to respond before the security problem went public and could be exploited.

Developers cried out that Twitter was shutting down technology essential to their business without warning - and not for the first time. Robin Wauters wrote a post on TechCrunch channeling developer anger over the shut-off. (Lest we imply too much criticism we'll note that we've written very similar stories ourselves.)

Twitter was widely criticized - and they kept their mouth shut, saying only that it was a temporary problem that would soon be resolved. "I can't stress enough how noble Twitter's behavior was yesterday," Hammer-Lahav told us. "Twitter bashing is a sport now and it's a sport that sells ads. Techcrunch wasn't aware of the security threat but it put Twitter in a position where if they were going to talk about it then they would put other companies at risk. We told Twitter that it was going to go public so do your own PR management and they did a good job. The emails sent by other providers to Twitter thanking them for taking that hit have been amazing."

After contacting Twitter, Hammer-Lahav started emailing all 30 companies listed as OAuth providers with Chris Messina's help. Half of them had representatives at FOOCamp, the event he was calling from. He explained the problem to them as he was able to reach people and asked them not to discuss it until next Thursday, one week later. He knew it would be a difficult secret to keep with so many parties involved, including the frustrated developers trying access all of those companies' OAuth APIs.

"At first it took me half an hour to explain the problem," he says. "By the next day I had the explanation down to 30 seconds." Within 12 hours the group discussing the problem knew there was no simple solution - it could require changes by OAuth providers and outside applications that consume OAuth permission in order for everything working again.

The group of OAuth providers formed an email list to discuss the problem and fifty people from 30 companies joined in. Deciding to focus on communicating with the initial service providers was a decision that had to be made. "You have to triage the parties involved," Hammer-Lahav says. Providers needed extra time to deal with the problem because they couldn't just plug the hole or pull the plug easily; FireEagle, for example, only has an OAuth API - there's no other way for the service to function.

OAuth is being advanced by a decentralized community of developers and other parties, but Eran Hammer-Lahav has been its most visible advocate. He's gained years of experience in the trenches fighting for a variety of open standards. He talked to every OAuth provider on the list and volunteered to act as the Community Threat Response Contact. Yahoo, his employer, told him to take as much time and do whatever he needed to deal with the problem. The company put Allen Tom in charge of Yahoo's response and donated Hammer-Lahav's paid time to the community effort. "If I was working for a different company this might not have been possible," he says. "Yahoo! had a whole team of people managing their own response to the situation."

All thirty companies sprung into action to neutralize the security risk and prepare their respective technical responses. Mashery co-founder Clay Loveless and team pushed back other work to pull all nighters and others pitched in as well. Everyone was an equal participant in working together, from single person startups to multibillion dollar companies. "Yahoo and Google put engineers on the line helping people with small startups to review solutions they were going to deploy," Hammer-Lahav says. "Usually the big guys figure it out amongst themselves and leave everyone else to their own devices. This felt like a real community. There was no liability because it was casual advice. Security people are expensive. Some startups don't even have in-house engineers, they are entirely outsourced."

One by one many of the providers shut down their APIs and one by one they implemented solutions.

By Wednesday, one day before the self-imposed period of silence was over, there had to be a lot of pressure built up behind the scenes. Alex Payne, the man in charge of the Twitter API and a guy who is much less grumpy than you'd probably be if you had his job, started getting visibly frustrated. "The view from under this bus is really something," he said on Twitter. "Nobody in the tech press has bothered to contact me for comment on the OAuth issue. Why bother with facts when speculation drives clicks?"

Just after noon on Wednesday, CNet's Caroline McCarthy reported that Twitter and others had pulled OAuth support because of a security problem in the spec. "In the interest of online safety," she wrote, "CNET News has chosen not to make the details of the security hole public." McCarthy was at FOOCamp as well and may have heard about the security issue then, but decided to more or less respect the wishes of the developer community and hold off writing about the issue at all until just before the deadline lifted. If that was the case then she both won accolades from involved parties for her discretion and got a lot of pageviews for jumping deftly on the story after the threat had mostly passed but before others wrote about it.

Minutes after the real story was out, Twitter posted about it on the company blog. Then the official OAuth blog posted about it, linking to McCarthy's post and publicly thanking Twitter for taking all the heat for days. Chris Messina worked fast to update the site and co-ordinate the community response. Then API service provider Mashery, the company that powers OAuth APIs for Netflix and many other companies, posted about it on its blog, assuring customers that the problem was small and under control and thanking Twitter as well. Finally Dave Winer, a web forefather and hardcore Twitter critic, made a post on his blog urging people to lay off Twitter and appreciate the way they were communicating with people about a number of intersecting and difficult technical problems.

One day later, one week after the community responding to the OAuth threat called for a week of silence to come up with a solution - Twitter announced that its OAuth API was back.

That was yesterday and by today almost all of the 30 OAuth providers have OAuth back up and running. There are two different long-term solutions in the works that are being debated on the email list as we speak. Hammer-Lahav says he expects a revised draft of the spec will be ready next week.

And that's how a decentralized community solved a security threat in an open identity spec, quickly. One company (Twitter) took a risk at implementing a new technology advocated by an employee of another company (Yahoo's Hammer-Lahav), then an engineer at yet another company found the beginning of the security hole, then news of the whole problem was sent out to contacts on a Wiki, an email list was formed, companies donated their employees' valuable time to aid in the effort, everyone more or less kept their mouths shut (including the unfairly criticized Twitter) and then everyone worked together to find a solution just in time. I think that's a pretty cool story.

Lessons for the Future

Hammer-Lahav took the lead in responding to this crisis and says he did it with the future of crisis response in open web communities in mind. Creating a template now for the future is only so possible, though. "In a year this same approach isn't going to work because too many businesses are going to depend on the providers," he says. "If we don't find a way to deal with this in the future then companies will remain very cautious about relying on multiple data sources." He says that people want to create a database listing all the parties involved in technologies like this, but prioritizing who gets talked to first will depend on the nature of the threat.

Finally, Hammer-Lahav says that more companies need to empower more employees to step up and take leadership in this kind of situation. The combination of technical, people and process skills is rare but those people need to be found. "It's not sufficient to have only Chris Messina and I as the two people who can do this," he told us. "We need other companies to step up and say there are people in their organization that can support the community. Yahoo said 'you're going to go do this for the community for as long as it takes,' Yahoo was paying me to manage the community threat in a way that was not purely in their self interest."

Can open communities advocating for an open web respond quickly and effectively to inevitable security issues? It sounds easier said than done, but for now we've got at least one very interesting story that says it is possible.

The team at inuda - Jonathan "@madmotive" Markwell specifically - reports that 150 other developers have been selected to participate in the OAuth private beta.

And then there's the Twitter OAuth page, that allows developers with registered apps to review their applications using Twitter. Chris Messina shares the beta user view, as well.)

How do you know if you're in the beta? According to the Twitter Development group:

"If you're one of the 150 or so people included in the closed beta your settings page (http://twitter.com/account/settings) now contains a 'Connections' tab. In the sidebar is a little information and a link to register your very own application."

Needless to say, the news was well received by the Twitter development community.

Granted, Twitter OAuth is only in limited beta, but given Markwell's tweets and the inuda post it appears to be a straightforward implementation:

"We managed to get a prototype up and running within a few minutes with no problems so we think it's fair to say that you should never give your Twitter password to anyone ever again. In a few weeks all developers of Twitter applications will have access to OAuth and they'll have no excuse other than laziness for not using it."

Could we be seeing the end of apps that ask for your Twitter password? Will OAuth make an appearance in tomorrow's release of Tweetdeck? We can only hope.

If you'd like to befriend the ReadWriteWeb staff on Twitter here are our accounts - we'd love to meet you too!

Plaxo and Google have collaborated on an OpenID method that may represent the solution to OpenID's biggest problems: it's too unknown, it's too complicated and it's too arduous. Today at the User Experience Summit, Plaxo announced that early tests of its new OpenID login system had a 92% success rate - unheard of in the industry. OpenID's usability problems appear closer than ever to being solved for good.

Plaxo, primarily known for the noxious flood of spam emails it delivered in its early days, is now an online user activity data stream aggregator owned by telecom giant Comcast. The Plaxo team has been at the forefront of the new Open Web paradigm best known for the OpenID protocol.

The Flow

The method Plaxo has been testing is called an OpenID/OAuth combo, in collaboration with Google. What does that mean, in regular terms? It means that Plaxo told users they could log in with their Gmail accounts as OpenID by clicking a link to open a Gmail window, then Google asked for permission to hand over user contact data using the OAuth standard protocol. Once login was confirmed, whether contact data access was granted to Plaxo or not, the Gmail window closed and users were returned to Plaxo all logged in. No new accounts, no disclosure of Gmail passwords to Plaxo, no risky account scraping and no need to import or find friends on the new service before immediate personalization could be offered.

This is a very different flow than most OpenID "relying parties" have followed before - but it won't be for long.

The Success Rate

Plaxo reported today that it has seen a staggering 92% of users who clicked on the "log-in with Gmail" button come back to Plaxo with permission to authenticate their identities via Gmail granted. Of those who returned, another 92% also granted permission for Plaxo to access their contacts list. Only 8% of the people who clicked to log in with a standards based 3rd party authentication ended up deciding to bail instead. That's the kind of ease-of-use that people presumed only Facebook Connect could provide.

When Plaxo engineers moved to turn off the short-term experiment, the business team said no way.

We expect to see this basic flow get iterated on even further. We hope it will ensure that every OpenID provider has some exposure and not just the big email providers, and we expect the pop-up action to be made increasingly unobtrusive.

This could be the day when OpenID became a far more realistic prospect than it has seemed before.