That day has come. The Google Contacts API went live tonight and it enables far more than just contact transfer.

• Synchronize Google contacts with contacts on a mobile device
• Maintain relationships between people in social applications
• Give users the ability to communicate directly with their friends from external applications using phone, email, and IM

"The Contacts API allows developers to create, read, update, and delete contacts using the Google Data protocol, based on AtomPub," the announcement says. "It also allows for incremental sync by supporting the 'updated-min' and 'showdeleted' parameters."

Pretty hot read/write stuff and particularly interesting given today's developer launch of the location tracking Fire Eagle from Yahoo!

One thing Fire Eagle has going for it that the Google Contacts API does not is support for the open authentication standard oAuth. Support by Google for oAuth in this API would have reduced the work required for developers by allowing code from other authentication proccesses to be reused. Google is supporting oAuth in OpenSocial, but on some days that hairball is harder to get excited about that a nice simple API like this one that delivers clear value.

Today's a big day for developers, may the secure Gmail contact leveraging begin!

Unfortunately that's what we're asked to do with a lot of new applications these days. It doesn't have to be that way, though.

Twitter

Senior Software Engineer at Twitter Britt Selvitelle said today in a conversation for developers working with Firefox that Twitter "will be using OAuth as our primary form of token auth."

That's fantastic news for a few reasons. Twitter is a very important communication tool for many people, the service's Application Programming Interface (API) has allowed a huge ecosystem of interfaces and applications to flourish around it...and yet today all of those 3rd party apps have to ask for your Twitter password in order for you to use them. It's been an awful lot of risk for users to take and we're really surprised that no one has yet ripped Twitter passwords from unsuspecting users and then unleashed a wave of valid looking spam.

Finally, it appears, Twitter will soon implement a secure way for you to give 3rd parties access to parts of your account without giving them a copy of the key to walk in the front door any time they like.

Firefox

The conversation today took place in the context of a question from Matthew "lilmatt" Willis, a Flock employee and longtime contributor to Mozilla. Willis wants to know if the Firefox developer community would like OAuth built into Firefox and if so how. He points out that much of the work has already been done, if not multiple times.

We're not entirely sure what this would look like, but we are intrigued. Browser-based authentication for data mashups sounds great. Browser plug-ins that securely access your various accounts without asking you for your passwords sound great too.

As of this afternoon there's a developer preview of a browser-based OpenID implementation for Firefox (thanks Vidoop!) so we hope that an OAuth implementation for Firefox could be a complimentary project.

The Big Picture

Google adopted OAuth for all the Google Data APIs this summer, so there's really no reason why 3rd party apps should ask you for any Google passwords ever again.

This is all very good news for everyone. Secure user authentication equals greater user trust, which equals developer access to more user data. More developer access to user data equals more innovation. More innovation makes us happy (we love this stuff) and, co-incidentally, leads to more user data. Data portability is good for everyone. Bring it on, Twitter and Firefox!

"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

WordPress announced last night on the company blog that WordPress.com users have a new blogging option called "Turbo," which uses Google Gears to speed up the service's admin functionality. Just an hour earlier, WP founder Matt Mullenweg indicated that users should look for OAuth support in future versions of the software.

The new WP.com Turbo feature uses Google Gears to download more than 200 files to users' local computers so they can be run without accessing the web. Though many of the most high-profile Gears implementations elsewhere are focused on providing off-line functionality, it's not clear whether that's the case here or if Gears is just being used to speed up blogging. Either way, this is good news. With the new feature, WordPress.com effectively offers what is called a Rich Internet Application (RIA), combining the responsiveness of local actions on the desktop with the connectivity of the web.

RIAs are already shaping up to be a powerful part of the web. Local storage and user interaction with at least some data fleshes out the possibilities offered by the celebrated migration towards web applications.

This is probably only the beginning for WP support of Gears. We wonder whether the WP developer community will build extensions that leverage WP support of Gears, perhaps even incorporating Gears support for mobile devices. Oh, the possibilities are a thrill to consider. The draft version of WordPress.org, scheduled to be released in final form within the next two weeks, already includes support for Gears as well.

OAuth

OAuth is a user authentication protocol that is quickly becoming a standard. It's all about making mashups fast, easy, secure and thus more common. When Google rolled out OAuth support for all its data APIs earlier this week, we said it was only a matter of time until almost every one else did so as well.

WP's Matt Mullenweg said last night that he wants to see OAuth support in WP but wouldn't be able to include it in the next version. Can we expect to see it in the next version then? We certainly hope so.

What might OAuth support in WordPress look like? There are a number of directions it could go. By supporting inbound OAuth authentication, WordPress could do things like allow you to post to your blog through 3rd party applications without giving them your password. It could also allow blog commenters to associate their accounts on other OAuth supporting services with their WP comments, again without giving up their passwords.

For blog publishers to be able to get secure programmatic access to their reader's data from other services would be very exciting. You don't want to give some random blog your Google Accounts password, but imagine if you could see all the comments ever left on that blog by your Gmail contacts - without giving up your password. That would be great.

There are probably far more possibilities than we can imagine, but that's what makes WordPress so exciting. There's a huge world of plug-in developers that extend the service in ways that none of us could imagine. With OAuth support those developers would be able to leverage a whole new class of options based on secure user data. That means WP blogs could tie in programmatically with any of your Google accounts, your Photobucket account or any other service that supports OAuth in one direction or the other. That's exciting to imagine and it sounds like it should be coming soon.

We're excited to see that WordPress isn't just relying on its developer community to keep it fresh and hip with the times. These new core developments will serve as a foundation for those developers to improve even further on the WordPress user experience.

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.

The spec got a burst of publicity earlier this week when the widely used feed reader Bloglines announced that they intend to support it in addition to OpenID and the Attention Data standard APML.

In this post I offer a high-level overview of what OAuth does, in as much as I understand it, followed by some thoughts on the concepts from some helpful industry experts.

Standards are the railroad tracks to a potential explosion of innovation and OAuth aims to make mashups far easier to develop than ever before. The group of developers took what they believed to be the best qualities from a long list of other authentication protocols and created an open standard they believe will make mashups safer to use and simpler to develop.

What Will This Look Like?

Here's one example of what OAuth might look like. There are lots of services like Twitbin or Twitteriffic that let you use your Twitter account in a much more powerful way outside of the Twitter web page. Those applications ask for your Twitter username and login, though; OAuth will let these apps interact without users exposing their full login info.

In that, OAuth is like OpenID, but this protocol will let services that hold your data offer a set of rules and options for allowing other applications to access selected parts of it. You could login to Twitter through Twitterific but only give Twitterific access to read and write messages - not to change your user profile page, your password or do anything else that they could in theory do today with full access to your account.

Is This Really Going to Happen? Let's Ask Some Experts

Making open standards real doesn't sound like a lot of fun, but the OAuth group seems to have a good start. The spec is being worked on by people from Google, Amazon, Yahoo/Flickr, Six Apart and all the three leading microblogging services. Implementation is expected soon by Netflix, Threadless, Bloglines, Twitter, Jaiku, Pownce, Ma.gnolia and others.

Agreeing on the final draft of the 1.0 spec is likely the last thing companies are waiting on and that's something that's happening a lot faster with OAuth than with OpenID 2.0, for example. Scott Kveton, Chairman of the Board of the OpenID Foundation, told me he thinks OAuth is another exciting move towards data portability and user control. He said that the small group involved in the spec is a real benefit when it comes to speed of development but that they will still have to struggle with IP like copyright before implementation really takes off with large players.

Oren Michels, of the recently funded API management service Mashery, says that OAuth could save his team a lot of valuable time currently spent working with the particulars of each non-standard API. He also told me, though, that many of his customers already have their own APIs built and would not likely go back and make them standards compliant. Ultimately, he said, good APIs are more important than standards compliant ones. In the future, companies that learn about OAuth early in the development of their APIs could implement it if there's sufficient market adoption.

Finally, I talked to John Musser of API super-site Programmable Web. Musser said that he's long argued that security is the number one barrier to further mashup proliferation and OAuth appears to address that well. "Higher value, 'personal mashups' require access to more interesting data than you can get without some secured access," he said, "but of course it's also an area lacking in standards, certainly from the perspective of the current generation of web 2.0 APIs." Musser also agreed with Michels that good APIs are more important than standards; he said that mashups are perfectly buildable today with the current circumstances but that a standard like OAuth could make a big difference by easing the complexity for developers.

Only time will tell whether OAuth has legs - but given the parties participating and the potential power of the standard, it may not take too much time to get a good look into the future.

When Google pushed out the Contacts API we called it "the most in-demand API on the web" that hadn't yet existed. These APIs are important because they allow socially aware applications to offer users the ability to import information from their address books without having to worry about giving up their password to a third-party site. The application seeking the information also no longer needs to employ any screen scraping to gather information.

Like Google and Microsoft, Yahoo! opted to employ their own authentication technology in the API, called BBAuth. Yahoo! intends to supports OAuth in the future, though, which will make it easier for developers to use the API. "Support for OAuth is coming, my friends, in due time... Seriously," wrote Wu. "At Yahoo! we're already doing a lot with OAuth (think Fire Eagle) and it's a big part of our plans."

The API is currently limited to 5,000 queries per IP address per day.