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.

With Appcelerator's new mobile offerings, web programmers can avoid the pitfalls of Objective-C or Java, and use basic Javascript, HTML, and CSS to build their apps.

Unlike competitor PhoneGap, Titanium claims it is better equipped to gain entry into the iPhone and Android app stores. The company believes its tools create applications that behave, look and feel identical to native iPhone applications. The idea is that Apple will be less likely to cast Titanium applications from the garden of appland after being made in the image of its predecessors.

To request access to Titanium's mobile beta fill out the form.

Usability

One of the main problems with OpenID, a technology that allows you to use the same set of credentials to sign into any service that supports this standard, is that it is often confusing to mainstream users. A number of large vendors that support OpenID, including Yahoo, MySpace, and Microsoft, have started to develop best practices for using OpenID, but to us, this extension for Flock might just represent one of the best solutions we have seen so far.

The extension is based on Vidoop's work on 'Identity in the Browser,' which has also resulted in an interesting OpenID solution for Firefox.

Flock, of course, does not have a very large user base, but other extension and browser developers will hopefully use this as an inspiration to create similar features for other browsers in the near future.

IDIB OpenID for Flock from phatbuddhaz on Vimeo.

After we wrote about Google becoming an OpenID provider yesterday, a number of reports suggested that Google was not following the OpenID guidelines closely and that it was basically forking OpenID to suit its own agenda. ]]> blog post to its Google Code Blog that explains why Google chose this implementation and how it will address these concerns in the future.

Confusion

Normally, when you use your email address as your OpenID credential, the OpenID enabled site (the 'relying party') goes back to your OpenID provider and looks for a specific file (XRDS) on the server. However, Google chose not to implement this part of the OpenID ecosystem when it launched its OpenID implementation yesterday and made developers rely on Google's own API instead.

Now, however, Google has announced that it will start publishing XRDS files 'as quickly as possible.' For the time being, you can use 'https://www.google.com/accounts/o8/id' to sign up for OpenID enabled sites.

Why Google Doesn't Accept OpenID Itself

One other issue many people raised yesterday was that Google itself did not accept OpenID for letting users sign in to its own properties. According to today's blog post, the reason for this is purely technical, as "all Google rich-client apps would break if we supported federated login for our consumer users." Google, however, is looking at possible solutions for these problems and is enlisting the help of the OpenID community.

It is good to see Google acknowledge these issues head-on. Despite these growning pains, we still think that Google's support for OpenID will drive its widespread acceptance, especially once Gmail users can just use their accounts to effortlessly create accounts and log into third-party services.

Note: Yesterday's espiode of TheSocialWeb.tv has some more in-depth detail about the development of Google's OpenID implementation and features an interview with the developers.

You may be wondering why you should use a Firefox plugin to create a wish list instead of simply using Amazon's new universal wish list service. The reason is openness. Where Amazon's tool comes from what is somewhat of a closed platform, Giftag is using an open data format: hProduct.

hProduct is an emerging data standard that is suitable for embedding in (X)HTML, Atom, RSS, and arbitrary XML. The format will be related to several other microformats like hListing and hReview. Since we like to support open standards here at RWW, we like what Giftag has done.

The Giftag Homepage

How It Works

Using Giftag is simple, especially if the site you are on already supports hProduct. You just click the button in your Firefox toolbar and, at the bottom of the screen, a tray will appear where all the information about the product (name, description, price, etc.) displays. All you need to do is select which of your lists to put the item on. If the retailer's site doesn't support hProduct, you're still able to add items to the list by drawing a box around the item, but you'll have to fill in the information about the product yourself.

All the lists you create can be selectively shared with others. You could choose some lists to be shared with family and friends and others could be shared publicly. You can also share your items with your friends on Facebook via the Giftag application. Developers can access Giftag APIs to build applications of their own.

The value of the hProduct standard is clear when you use an application like Gifttag. Given Best Buy's involvement, we hope that this will push more retailers into adopting the standard on their own sites. A web of retail sites that support the same standard could open the door to even more applications that take advantage of the standard - and that's something we would like to see.

On the other hand, as Zac points out, getting some of this functionality into applications now would definitely help putting some pressure on Apple to release this functionality quickly. After all, there are a good number of applications that just aren't very useful without being able to copy and paste (blog clients, text editors, email clients, etc.).

Zac also notes that he doesn't think that Apple is trying to squash OpenClip on purpose, but it does seem as if Apple is creating a bit of a moving target for developers. Given Apple's penchant for secrecy, every developer who is trying to write an application that gets relatively deep into the OS has to fear that Apple might just close off some necessary functionality without warning.

So, what, exactly is Genome, then? Well, it's not really just one thing - it's four:

1. Social Network: Genome a social network like any other. You'll have a user profile, friends, and tools that let you social with them in comfortable, natural ways.
2. Contact Manager: You'll be able to keep track of your contacts' information on Genome.
3. Instant Messenger: Genome will provide an open instant messenger that's integrated with your contacts.
4. Identity & Social Graph Provider: Genome will have an open identity policy so your Genome identity is easily sharable with other sites. That means that other sites and services can query Genome for some pieces of your personal information.

The Genome project has only been in development for three months and most of the details on how it operates, technically speaking, are being kept quiet. However, we got a look at some of their plans as well as some screenshots of the mobile app.

What Genome Is Not

Genome is not an aggregator spock.com profiles or FriendFeed. Genome can function as your central identity, not a collection of your identities out on the web nor a collection of your social web activities.

It's not a competitor to other data portability movements like Facebook Connect, MySpace's Data Availability, or Google Friend Connect. Instead, Genome will work cooperate with them to give users control over their own data. To do so, Genome will not use any closed, proprietary protocols - only open standards.

What Genome Will Let You Do

Because it will use open protocols, the goal is to let users carry their identites anywhere on the web. Updates made to those identities out on the web will make their way back to Genome instead of users having to return to Genome to edit their profiles.

You'll be able to access Genome's service from a web app, a desktop client (they have a Windows, Mac, and Linux client planned), and a mobile app. A Google Android client has already been built, too. In fact, Genome's creators are particularly focused on the mobile market and are working on real-time sync and location awareness in this area. Of course, developers will also be able to build their own web apps and clients thanks to Genome's open standards and API.

We got a sneak peek at the Android app, but be warned, the app is still very much in alpha and may change a lot prior to launch:

To deal with "noise" Genome is implementing something they're calling a "real-life relationships" model. In your real life, says co-founder Chernyshov, "you can control who knows what about you, and you can control what you know about them." Those granular relationships will be available on Genome, yet kept as simple as possible.

How You'll Use Genome (At First)

There aren't too many details on the specifics of how you will use Genome or the technical details as to how Genome operates, but we do that the first public release will only be the beginning of their effort to solve all the problems noted at the beginning of this post. The first iteration of Genome will be focused on the problem of identity management.

In the area of contact and identity management, the problems that Genome wants to solve specifically include the following: you can't import or export data on today's social networks, you can't control who sees what about you, you can't watch who knows what about you, and you can't ask a new web service to retrieve your name, email, contacts, etc. from a social network site. Well, as for that last issue, data portability is supposed to address this, but perhaps Genome's creators aren't interested in waiting for the major providers to make it work.

To start off, you'll be able to import your address book contacts and (possibly) import friends from various social networks. (They aren't sure if they will have that feature ready for the first public launch or not). However, they do plan on supporting Google Friend Connect and, further down the road, they will offer automatic contacts discovery.

Once you add a contact to Genome, it's yours - it's not locked in any way. Unlike a network like Facebook, for example, who locks in your contacts so you have to keep using their walled garden service, the data from Genome can be freely moved about the web. If you add someone to Genome then invite them to join the service, their profile will be automatically linked with the contact you've already created. The details don't need to be re-entered.

Other Issues Being Addressed

As the Genome project progresses, future versions of the service will focus more on privacy concerns, distractions, quality interactions, and advertisements. (More details can be found on this post about Genome.) How these issues will be dealt with is currently under wraps.

Privacy: Privacy levels will be set up to mirror real-life relationships: spouse or significant other, family, best friend, friend, buddy, colleague, business partner, high school acquaintance, contact, etc. Human relationships have detailed nuances - social networks should, too.

Distractions: Social networks today are bogging us down with messages, invitations, pokes, and friend requests. Some of these matter, some of these waste our time, but how can we pay attention to only the really important things? Genome plans to address this.

Quality Issues: The more "friends" you have, the less rich the interactions and the relationships you maintain with your friends on your social networks. Interactions become one-way, more similar to RSS than to real relationships.

Ads: Today's ads are often irrelevant, usually unwanted, and sometimes even inappropriate. Even targeted ads seem to miss the mark. If Genome truly has a solution for this problem, that will be extremely impressive.

Conclusion

At the moment, Genome sounds almost too good to be true - a social networking service that solves all our problems? Nevertheless, it's certainly intriguing. If it can really do what it proposes to do, then it's worth signing up for (sign-up is here).

Facebook Requests: Dan Zen